Re: [ietf-dkim] double header reality check
At 17:53 19-10-10, Mark Delany wrote: In a DKIM world a list server could reasonable use DKIM to bypass this confirm sequence and make your life a bit simpler. Perhaps it relies on Authentication-Results or somesuch. In any event such a list server is actually *more* vulnerable than it is today if we let thru bogus payload that appear to be valid. According to Section 7 of RFC 5672: For DKIM processing, the domain name portion of the AUID has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. Furthermore, in Section 8: A module that consumes DKIM's mandatory payload, which is the responsible Signing Domain Identifier (SDID). The module is dedicated to the assessment of the delivered identifier. Other DKIM (and non-DKIM) values can also be delivered to this module as well as to a more general message evaluation filtering engine. However, this additional activity is outside the scope of the DKIM signature specification. Based on the above, I don't think that a list server could use DKIM to bypass the confirm sequence. Regards, -sm ___ 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 Mon, 18 Oct 2010 18:06:14 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John Levine Sent: Friday, October 15, 2010 7:14 PM To: ietf-dkim@mipassoc.org Cc: dcroc...@bbiw.net Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. OpenDKIM returns a syntax error in both cases. And to complete the picture, what does it do when verifying? -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
On Wed, Oct 20, 2010 at 01:41:03AM -0700, SM allegedly wrote: At 17:53 19-10-10, Mark Delany wrote: In a DKIM world a list server could reasonable use DKIM to bypass this confirm sequence and make your life a bit simpler. Perhaps it relies on Authentication-Results or somesuch. In any event such a list server is actually *more* vulnerable than it is today if we let thru bogus payload that appear to be valid. According to Section 7 of RFC 5672: For DKIM processing, the domain name portion of the AUID has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. Furthermore, in Section 8: A module that consumes DKIM's mandatory payload, which is the responsible Signing Domain Identifier (SDID). The module is dedicated to the assessment of the delivered identifier. Other DKIM (and non-DKIM) values can also be delivered to this module as well as to a more general message evaluation filtering engine. However, this additional activity is outside the scope of the DKIM signature specification. Based on the above, I don't think that a list server could use DKIM to bypass the confirm sequence. Well, that's should. It also assumes that all subsequent users of DKIM bother to read and obey. It also assumes that future users of DKIM won't get inventive and use DKIM in ways that we can't even imagine. I think that undersells DKIM and future users. Just ask the inventors of DNS whether they thought we'd be using it the way we are... or whether we're using it the way they intended. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Tue, 19 Oct 2010 16:23:39 +0100, John R. Levine jo...@iecc.com wrote: good signature - good message. Don't you mean Good signature - authenticated message (that is, someone accepts responsibility) I think it needs to mean Good signature - authenticated message (that is, someone accepts responsibility, where someone is identifiable at least to the extent of being or not being the domain in whatever From: is shown). When I said good, I meant credible, not just one that mechanically validates. I hope that we all agree that a signature from a domain about which one knows nothing is not usefully different from no signature at all. A reputation service can only say that a domain is BAD GOOD or NO EVIDENCE AVAILABLE EITHER WAY. I think the last case has to be treated pretty much like GOOD, otherwise newcomers to the internet will never even get their messages accepted. There might be some merit in a repuation service responding with DOMAIN CREATED WITHIN THE LAST 15 MINUTES although even that should have been Domain first used within the last 15 minutes, except I cannot see how a reputation service coulr know that. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On Tue, 19 Oct 2010 14:18:45 +0100, Wietse Venema wie...@porcupine.org wrote: My preference would be to enforce this within the existing protocol (that is: send h=from:from:subject:subject...), But that only copes with some of the scams that are possible; for full protection you need ... but I could live with hard-coded checks for unsigned single-instance RFC 5322 and MIME headers (that is: no DKIM PASS for unsigned extra From, Subject, MIME-Version, Content-type, etc. headers). -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
On Mon, 18 Oct 2010 20:18:16 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: This is no more presumptuous than expecting that MUAs will adapt to consume the output of DKIM as it stands now. In another message I indicated that I don't presume either, but assert that there's no middle ground; they will or they won't. If they will, informative text is sufficient; if they won't, then we have to start hardening MTAs to defend against MUA attacks because that's where header changes and other enforcements are possible since, by definition, any current annotations are invisible and will stay that way. I'm fine with accepting either model, but we have to understand the implications of picking one. The latter, in particular, involves some major scope creep. No it doesn't. I believe they won't (at least not on any short enough timescale). But we are already in the hardening business, because the basic assumption made by DKIM was that the verification (and resulting action) could and would be done at the boundary layer as part of, or closely associated with, the final MTA, and without any change to existing MUAs. What options for 'action' are available at that point (or were envisaged as being available at that point when DKIM was first written)? I can think of discarding (silently or noisily) increased spamassassin score warning to the end user (e.g. in a changed Subject header) So all we need is to ensure that those same actions will be activated by this new threat; in which case the language to bring this about needs to be just as normative as in the rest of the DKIM specification. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
--On 20 October 2010 15:12:47 +0100 Charles Lindsey c...@clerew.man.ac.uk wrote: When I said good, I meant credible, not just one that mechanically validates. I hope that we all agree that a signature from a domain about which one knows nothing is not usefully different from no signature at all. A reputation service can only say that a domain is BAD GOOD or NO EVIDENCE AVAILABLE EITHER WAY. Actually, a reputation service could offer a score that's more subtle than good/bad. And, it could offer address reputation rather than domain reputation. That would be far more suitable for domains like the large email service providers, which have a mix of good and bad users. http://www.dkim-reputation.org/start/ offers address based reputation service. I've not used the service, so can't vouch for it. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
--On 19 October 2010 07:31:58 -0700 Michael Thomas m...@mtcc.com wrote: On 10/19/2010 06:18 AM, Wietse Venema wrote: valid signature + good signer + no suspicious unsigned content - good message Has nobody learned that good signers from good authors can still be evil? I mean come on, people, bot'd machines? This is horrible advice. s/unsigned/; and this works. Mike Well, everything's relative. If we can get to the point where a bot'd machine can only send email From: it's real owner, that'll be a huge improvement on the current situation. At that point, we can start to pressure the real owner into fixing their machine (say, by emailing them or their domain support, or by blacklisting their email) -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
--On 19 October 2010 11:35:53 -0400 John R. Levine jo...@iecc.com wrote: True, but there already are UI designs that indicate when a From header is DKIM verified. So you're saying that all a spammer has to do is to put on a throwaway domain's signature, and the MUA will highlight at least parts of the message with green goodness? Surely our understanding of domain reputation is better than that. I believe that's the basis of this whole discussion, isn't it. The point is that the MUA tells you whether the header was signed, and leaves you to apply the domain or address reputation. I think that's a step forward. At least, it is when I know the purported author. And, surely I'm better at assigning reputation to -say- my brother than any automated system is. But, hey, I'm on your side here. I think we should put a warning in the RFC so that vendors are informed that they need to be sure they're highlighting the correct header. Any chance you can tell me which MUAs have this misfeature, so I can tell people to return them and ask for a refund? R's, John -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ 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
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Wednesday, October 20, 2010 3:52 AM To: DKIM Subject: Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. OpenDKIM returns a syntax error in both cases. And to complete the picture, what does it do when verifying? I'm not sure what you think both meant, but I meant it as when signing and when verifying. I don't know of any other DKIM operating modes. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
A reputation service can only say that a domain is BAD GOOD or NO EVIDENCE AVAILABLE EITHER WAY. I think the last case has to be treated pretty much like GOOD, otherwise newcomers to the internet will never even get their messages accepted. Heck, no. Treat it like there's no signature at all, and filter it like one does now. I hope the difference between whitelisting and filtering doesn't require further explanation. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Tuesday, October 19, 2010 5:53 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] double header reality check Any filter or agent that makes any kind of filtering, routing or sorting decision based on any header field which in turn presumes there's only one such field without actually checking is a potential security concern. I think this is a subtely different problem though. All of the examples you cite (and all other pre-DKIM examples for that matter) are foolable with a single forged header today. That they could be further fooled with multiple headers is not an issue. In a future world where such tools (and UAs) could act with authority because DKIM has assured the headers/payload is where we have the problem. Only once tools and UAs take advantage of DKIM, do these attacks become relevant. That's why I think this is a DKIM problem. We are wanting tools and UAs to take advantage of DKIM but by doing so they are possibly making themselves more vulnerable to attackers. [...] IOW. Asking them to rely on DKIM is a backward step. I do understand the difference. And I am not ignorant to the fact that any mail system component that's offered some new trust mechanism which has inherent exposure risks is not likely to adopt that mechanism anytime soon. Plenty of examples exist, even in the email space, some of them fairly recent. The job of a designer of such a mechanism (or any mechanism really) is twofold: (a) reduce risks as much as is practical, and (b) fully expose those that remain. Both of these are easily accomplished by a specification that is clean and thorough. Anyone who's shipped a product that can be tough to use knows that complete user documentation of the issues makes even a tricky product palatable to customers. Forewarned is forearmed. I think a lot of this discussion conflates protocol specification with implementation. I'm focused on the former. I maintain that including wording intimating that a DKIM implementation is non-compliant if it fails to do mail format validation prior to accepting input or returning a result causes the specification not to be clean. It's a layering violation. It's sloppy design. It shouldn't be done. The difference may be as subtle as what you're talking about above. For example, although I am arguing that RFC4871bis shouldn't contain any kind of normative enforcement of other specifications, my own open source implementation already does it and has almost since day one. I think that's the right thing to do, not because RFC4871 told me to, but because RFC5322 did. And as a result, it's in the part of the code that deals with mail, not the part that deals with DKIM. It also does all kinds of validation that the data it got back from the nameserver on a key or policy query conforms to the expected format of a DNS query described in RFC1034, because if it doesn't (which does happen sometimes, four so far today in the logs) then running with those bits can have nasty side effects. But RFC4871 doesn't, and shouldn't, require that checking. That syntax is defined in RFC1034. Or are you folks also saying we should add text to RFC4871bis mandating validation of the results returned by functions like res_send()? Suppose a chthonic hacker could send DKIM-signed mail that causes his DNS server to be queried, returning a reply that will somehow always validate (or crash). And suppose res_send() doesn't validate the payload, only passes it through to the caller. Isn't this just as dangerous? We are most certainly obliged to emphasize to consumers of DKIM output the distinction between what was covered by a signature and what was not, and lay out the possibility that such consumers could be confounded in the way that's been described. Failing to do so is a disservice. I'm all for putting that into Security Considerations in intricate detail with lots of examples of possible exploits. That, to me, is precisely why that section is mandated as part of all RFCs. I will happily write a sesquipedalian treatise on this topic to be included there if it resolves this issue. An aircraft comes with an operating handbook. The manufacturer goes to great pains to make the aircraft as safe and secure as possible. Ultimately, though, it's the pilot that crashes or lands, and thus learns the ins and outs of that particular aircraft by reading the ample documentation provided by the manufacturer before taking to the air. No, Doug, I don't think these checks belong in POP3, or IMAP, or SIEVE. They belong in whatever component is the one that decides when or whether seek or apply a DKIM result. Like I said before, it should be perfectly reasonable for a protocol specification to require something proper from the layers below it, and to
Re: [ietf-dkim] double header reality check
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, October 20, 2010 1:55 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] double header reality check SNIP There has been talk of applying DKIM to technologies like Usenet and HTTP output. Packing DKIM with mail-specific verification requirements could prevent such things from happening. Shall we also add a but only when used in the email context clause? Seeing as the M in DKIM stands for Mail, we don't have to put a but only when used in the email context clause. If a DKIM like approach is used for other protocols then we might reasonably text specific to those protocols - DKIH (Domain Keys Identified HTML as an example). Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, October 20, 2010 1:55 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] double header reality check SNIP There has been talk of applying DKIM to technologies like Usenet and HTTP output. Packing DKIM with mail-specific verification requirements could prevent such things from happening. Shall we also add a but only when used in the email context clause? Seeing as the M in DKIM stands for Mail, we don't have to put a but only when used in the email context clause. If a DKIM like approach is used for other protocols then we might reasonably text specific to those protocols - DKIH (Domain Keys Identified HTML as an example). I guess because we are already integrated with different mail formats, I don't see the difference other than having implementation specific setup features. For example a signing setup with a target rule Signer Domain::Target Domain where the association will enforce certain headers to be signed. In the case of usenet (or nntp specifically), the considerations might be: - enforce Path: header - enforce (maybe) Newsgroups: header - relaxed signing To: header (since its To: ALL for news) But if you want to see how email is gated into public newsgroup areas, check out news://news.winserver.com (use an anonymous account to login). You will see how newsgroups are used for various list. One for the IETF-DRAFT submissions and other list areas shown as local public newsgroups. One of interest where DKIM is used is the SPF-DISCUSS list/newsgroup where you can see the 10/17/2010 article titled: [spf-discuss] SPF Mail Summary Report and if you view the message source and headers, you will see the Authorization-Results: header: Authentication-Results: dkim.winserver.com; dkim=pass header.i=listbox.com header.d=listbox.com header.s=launch; adsp=fail policy=all author.d=winserver.com asl.d=listbox.com (unauthorized signer); dkim=fail (DKIM_BODY_HASH_MISMATCH) header.i=winserver.com header.d=winserver.com header.s=tms1; adsp=pass policy=all author.d=winserver.com signer.d=winserver.com (originating signer); When our system generated the weekly Summary Report, it was DKIM signed and exported to the spf-discuss mailing list. The list server than broke and resigned it and when the copy came back to us, it will DKIM verified and put into the newsgroup area. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] What shows up with duplicated headers?
Here's another batch of spam with extra From or Subject lines. I see the same thing as last time, the extra subjects are all the same, and the extra From lines look like bugs, not attempts to evade filters. The spam with 6,981 From lines is impressive in a wacky way. R's, John http://spample.iecc.com/oko/13513473 !!! from 2 subj 1 http://spample.iecc.com/mai/13527118 !!! from 1 subj 2 same http://spample.iecc.com/wnq/13527333 !!! from 2 subj 1 http://spample.iecc.com/xdg/13644660 !!! from 2 subj 1 http://spample.iecc.com/ydd/13658310 !!! from 2190 subj 1 http://spample.iecc.com/yic/13695408 !!! from 1 subj 2 same http://spample.iecc.com/gkj/13764008 !!! from 6981 subj 1 http://spample.iecc.com/joi/13772001 !!! from 2 subj 1 http://spample.iecc.com/sxt/13794463 !!! from 840 subj 1 http://spample.iecc.com/euf/13894583 !!! from 2 subj 1 http://spample.iecc.com/gix/13906201 !!! from 1 subj 2 same http://spample.iecc.com/bds/13961106 !!! from 2 subj 1 http://spample.iecc.com/jha/14009391 !!! from 2 subj 1 http://spample.iecc.com/ptl/14009501 !!! from 1 subj 2 same http://spample.iecc.com/ndg/14053973 !!! from 1 subj 2 same http://spample.iecc.com/ddz/14108277 !!! from 1 subj 2 same http://spample.iecc.com/pes/14209695 !!! from 2 subj 1 http://spample.iecc.com/kfd/14263497 !!! from 1 subj 2 same http://spample.iecc.com/qdg/14263705 !!! from 1 subj 2 same http://spample.iecc.com/eyp/14268312 !!! from 1 subj 2 same http://spample.iecc.com/uib/14277824 !!! from 1 subj 2 same http://spample.iecc.com/mcj/14278398 !!! from 1 subj 2 same http://spample.iecc.com/rwz/14317049 !!! from 1 subj 2 same http://spample.iecc.com/syi/14317050 !!! from 1 subj 2 same http://spample.iecc.com/ewh/14337217 !!! from 1 subj 2 same http://spample.iecc.com/keh/14349846 !!! from 1 subj 2 same http://spample.iecc.com/jtl/14351633 !!! from 1 subj 2 same http://spample.iecc.com/hqw/14360328 !!! from 1 subj 2 same http://spample.iecc.com/slz/14363168 !!! from 1 subj 2 same http://spample.iecc.com/oqu/14370756 !!! from 1 subj 2 same http://spample.iecc.com/shu/14370764 !!! from 1 subj 2 same http://spample.iecc.com/mqz/14390820 !!! from 1 subj 2 same http://spample.iecc.com/dxb/14392591 !!! from 1 subj 2 same http://spample.iecc.com/vcw/14393557 !!! from 1 subj 2 same http://spample.iecc.com/gkj/14393579 !!! from 1 subj 2 same http://spample.iecc.com/vef/14409312 !!! from 1 subj 2 same http://spample.iecc.com/xus/14410639 !!! from 1 subj 2 same http://spample.iecc.com/vta/14466945 !!! from 2 subj 1 http://spample.iecc.com/tvf/14477920 !!! from 1 subj 2 same http://spample.iecc.com/nbq/14512851 !!! from 2 subj 1 http://spample.iecc.com/wbt/14514852 !!! from 977 subj 1 http://spample.iecc.com/muf/14519415 !!! from 385 subj 1 http://spample.iecc.com/thg/14542167 !!! from 2 subj 1 http://spample.iecc.com/scg/14542263 !!! from 2 subj 1 http://spample.iecc.com/bia/14572469 !!! from 1 subj 2 same http://spample.iecc.com/hwd/14574906 !!! from 1 subj 2 same http://spample.iecc.com/eeu/14595557 !!! from 2 subj 1 http://spample.iecc.com/wsf/14601350 !!! from 2 subj 1 http://spample.iecc.com/kyr/14602820 !!! from 2 subj 1 http://spample.iecc.com/hsg/14607445 !!! from 2 subj 1 http://spample.iecc.com/pva/14609226 !!! from 2 subj 1 http://spample.iecc.com/mur/14632131 !!! from 1 subj 2 same http://spample.iecc.com/mua/14644824 !!! from 2 subj 1 http://spample.iecc.com/ych/14661976 !!! from 2 subj 1 http://spample.iecc.com/fuf/14689113 !!! from 1 subj 2 same http://spample.iecc.com/dsd/14723463 !!! from 1 subj 2 same http://spample.iecc.com/knx/14728696 !!! from 1 subj 2 same http://spample.iecc.com/mux/14728748 !!! from 1 subj 2 same http://spample.iecc.com/djd/14728829 !!! from 1 subj 2 same http://spample.iecc.com/epb/14728832 !!! from 1 subj 2 same http://spample.iecc.com/jdy/14740113 !!! from 1 subj 2 same http://spample.iecc.com/mxi/14750851 !!! from 2 subj 1 http://spample.iecc.com/qbm/14754069 !!! from 1 subj 2 same http://spample.iecc.com/yhz/14763567 !!! from 2 subj 1 http://spample.iecc.com/voc/14768732 !!! from 2 subj 1 http://spample.iecc.com/sal/14778601 !!! from 1 subj 2 same http://spample.iecc.com/snw/14800456 !!! from 2 subj 1 http://spample.iecc.com/kzw/14805611 !!! from 2 subj 1 http://spample.iecc.com/kta/14837567 !!! from 1 subj 2 same http://spample.iecc.com/cuw/14844705 !!! from 2 subj 1 http://spample.iecc.com/cwf/14844706 !!! from 2 subj 1 http://spample.iecc.com/paf/14884768 !!! from 1 subj 2 same http://spample.iecc.com/qcz/14884769 !!! from 1 subj 2 same http://spample.iecc.com/fpk/14887273 !!! from 1 subj 2 same http://spample.iecc.com/eoz/14893324 !!! from 2 subj 1 http://spample.iecc.com/aas/14935218 !!! from 1 subj 2 same http://spample.iecc.com/wcs/14935821 !!! from 2 subj 1 http://spample.iecc.com/dbf/14943578 !!! from 1 subj 2 same http://spample.iecc.com/ndo/14949600 !!! from 1 subj 2 same http://spample.iecc.com/ovs/14949602 !!! from 1 subj 2 same http://spample.iecc.com/czc/14952912 !!! from 1 subj 2 same
Re: [ietf-dkim] double header reality check
On 10/20/10 9:30 PM, MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, October 20, 2010 1:55 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] double header reality check SNIP There has been talk of applying DKIM to technologies like Usenet and HTTP output. Packing DKIM with mail-specific verification requirements could prevent such things from happening. Shall we also add a but only when used in the email context clause? Seeing as the M in DKIM stands for Mail, we don't have to put a but only when used in the email context clause. If a DKIM like approach is used for other protocols then we might reasonably text specific to those protocols - DKIH (Domain Keys Identified HTML as an example). Yep. Or other protocols will use parts of DKIM. Like with MIME (Multipurpose Internet /Mail/ Extensions); it has been used by other protocols as well. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] What shows up with duplicated headers?
John R. Levine wrote: Here's another batch of spam with extra From or Subject lines. I see the same thing as last time, the extra subjects are all the same, and the extra From lines look like bugs, not attempts to evade filters. The spam with 6,981 From lines is impressive in a wacky way. R's, John SNIP wow! I definitely have to pencil in time this weekend to scan the archives (I think I have some as far as 1998) to see how pervasive was this issue. Good show john. --- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
On 10/20/2010 01:31 PM, Rolf E. Sonneveld wrote: On 10/20/10 9:30 PM, MH Michael Hammer (5304) wrote: Seeing as the M in DKIM stands for Mail, we don't have to put a but only when used in the email context clause. If a DKIM like approach is used for other protocols then we might reasonably text specific to those protocols - DKIH (Domain Keys Identified HTML as an example). Yep. Or other protocols will use parts of DKIM. Like with MIME (Multipurpose Internet /Mail/ Extensions); it has been used by other protocols as well. Ages ago I, just for grins and giggles, implemented DKIM on SIP messages mainly so that I could say that DKIM-on-SIP had been implemented, while SIP-Identity (rfc 4474) had not. For all I know, that's still the case :) Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
On 10/20/10 10:55 AM, Murray S. Kucherawy wrote: I think a lot of this discussion conflates protocol specification with implementation. I'm focused on the former. I maintain that including wording intimating that a DKIM implementation is non-compliant if it fails to do mail format validation prior to accepting input or returning a result causes the specification not to be clean. It's a layering violation. It's sloppy design. It shouldn't be done. Disagree. Since DKIM /REQUIRES/, at minimum, the From header field be signed, are you suggesting layer violations when DKIM's verification process checks for non-compliant multiple From header fields? It would be negligent of DKIM not to return a result of PERMFAIL when multiple From header fields are detected. Clean layering of a verification process is /not/ achieved when consumers of DKIM results must re-examine messages that receive a PASS result. RFC5322 Section 6.4 amends the compliance required by SMTP, and removes strict enforcement. There is not even a clearly defined error code to report non-compliance. Since no layer below DKIM assures RFC5322 compliance, it is negligent for the DKIM verification process to skip checks for multiple From header fields. DKIM extends trust based upon the signing domain to include the From header field, as a minimum. Since normally there is no advantage obtained by introducing multiple From header fields without the additional trust established by DKIM, it becomes fully incumbent upon DKIM to check for illegal conditions that might lead to erroneous placement of trust. Failure in this regard is likely to result in trust related exploitations. The difference may be as subtle as what you're talking about above. For example, although I am arguing that RFC4871bis shouldn't contain any kind of normative enforcement of other specifications, my own open source implementation already does it and has almost since day one. I think that's the right thing to do, not because RFC4871 told me to, but because RFC5322 did. And as a result, it's in the part of the code that deals with mail, not the part that deals with DKIM. Disagree. DKIM MUST detect conditions that would allow trust established by DKIM to be exploited, where DKIM, at a minimum, includes the From header field. Specifying a DKIM result for multiple From header fields impacts ONLY consumers of DKIM results. This is not about enforcing RFC5322 compliance, this acknowledges that many processes assume there will be only a single From header field, as required by RFC5322. Violation of this expectation prevents any DKIM status other than PERMFAIL to be safely returned. It also does all kinds of validation that the data it got back from the nameserver on a key or policy query conforms to the expected format of a DNS query described in RFC1034, because if it doesn't (which does happen sometimes, four so far today in the logs) then running with those bits can have nasty side effects. But RFC4871 doesn't, and shouldn't, require that checking. That syntax is defined in RFC1034. DKIM Section 3.2 requires that tags with duplicate names *MUST NOT* occur within a single tag-list; if a tag name does occur more than once, the entire tag-list is to be considered invalid. Because many had trouble with the format specified in Section 3.2 for tag values that are space delimited, many did not want to use the colon delimited structure specified in section 3.6.1. Now many have decided to list the t= tag twice when adding the t=y value. A similar problem also exists with the g= tag. It is ironic that DKIM is having trouble ensuring strict format compliance for these unique DNS resource records. RFC1034 clearly indicates valid results without expecting the consumers of DNS to second guess their validity. However DKIM requires use of TXT resource records that are not required by SMTP. An intrusion into DNS that is also being overlooked. DKIM also specifies RFC3833 which warns against name chaining that also impacts the operation of DKIM validation. Or are you folks also saying we should add text to RFC4871bis mandating validation of the results returned by functions like res_send()? Suppose a chthonic hacker could send DKIM-signed mail that causes his DNS server to be queried, returning a reply that will somehow always validate (or crash). And suppose res_send() doesn't validate the payload, only passes it through to the caller. Isn't this just as dangerous? How would changing DKIM mitigate this type of threat? We are most certainly obliged to emphasize to consumers of DKIM output the distinction between what was covered by a signature and what was not, and lay out the possibility that such consumers could be confounded in the way that's been described. Failing to do so is a disservice. I'm all for putting that into Security Considerations in intricate detail
Re: [ietf-dkim] detecting header mutations after signing
On 10/20/10 8:10 AM, Ian Eiloart wrote: --On 19 October 2010 11:35:53 -0400 John R. Levine jo...@iecc.com wrote: True, but there already are UI designs that indicate when a From header is DKIM verified. So you're saying that all a spammer has to do is to put on a throwaway domain's signature, and the MUA will highlight at least parts of the message with green goodness? Surely our understanding of domain reputation is better than that. I believe that's the basis of this whole discussion, isn't it. The point is that the MUA tells you whether the header was signed, and leaves you to apply the domain or address reputation. I think that's a step forward. At least, it is when I know the purported author. And, surely I'm better at assigning reputation to -say- my brother than any automated system is. DKIM does not authenticate the From header field, however it provides authenticated DKIM domains that are, at a minimum, bound with the From header field. When the DKIM domain is Big-Bank.com, and you or your system trusts this domain, there should also be less concern related to whether a From header field containing accou...@big-bank.com offers deceptive information. But, hey, I'm on your side here. I think we should put a warning in the RFC so that vendors are informed that they need to be sure they're highlighting the correct header. Why? There would not be a problem when DKIM verification results return PERMFAIL when there is any doubt which From header field might be selected when more than one exists. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
On 10/20/10 3:19 PM, Murray S. Kucherawy wrote: [] I totally agree that that's an important distinction to make, document, highlight and shout from the rooftops. But... Does it *have* to use RFC2119 normative language? Here's maybe a better way to frame the question: Should we empower ourselves to label a DKIM implementation that doesn't do format enforcement as (a) non-compliant, or (b) low-security/low-quality? I'm pushing for (b), while someone who insists the text be normative is pushing for (a). a) please. In this case, low quality really means misleading results. Why are you reticent in adding obvious checks, that I am sure your code will include. Not making this a MUST return PERMFAIL for multiple From header fields otherwise means DKIM results can never be trusted. The results would not offer interchangeable implementations, since it is unreasonable to expect consumers of DKIM results will always make the relevant checks that might have been missed, or that SMTP will now suddenly alter its level of compliance checking. This is really about checks that will consume only a few CPU cycles, since the information is already touched by the verification process. What is a few picoseconds between friends? :^) -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote: Validating mail syntax belongs in the specification for the mail components and DKIM work belongs in the DKIM components. That's why, layer violation or no, I think it's important to distinguish between format errors that are likely to lead to misleading rendering in existing MUAs, and the much larger class that may produce nonsense but won't produce lies. I think we're close to converging here. I totally agree that that's an important distinction to make, document, highlight and shout from the rooftops. But... Does it *have* to use RFC2119 normative language? Here's maybe a better way to frame the question: Should we empower ourselves to label a DKIM implementation that doesn't do format enforcement as (a) non-compliant, or (b) low-security/low-quality? I'm pushing for (b), while someone who insists the text be normative is pushing for (a). I'm pushing for neither. It's not the DKIM verifiers responsibility to enforce that. I do think that an informative note observing Here are a couple of issues that might theoretically be exacerbated by a DKIM-using world; you might consider checking for these problems somewhere in your mail handling path, if you aren't already would be reasonable. Somewhere in your mail handling path might be in the same binary as the DKIM validator, or it may not - and implying that an implementation that chooses to handle two entirely separate validation issues in two separate modules is non-compliant or low-security or low-quality doesn't seem helpful. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
Here's maybe a better way to frame the question: Should we empower ourselves to label a DKIM implementation that doesn't do format enforcement as (a) non-compliant, or (b) low-security/low-quality? The latter. Hey, we agree. I think I always said SHOULD rather than MUST. The DKIM spec is a peculiar combination of instructions on how to produce a technically valid signature along with a great deal of non-normative advice, some of which is good (sign all the visible headers) and some of which is not so good (tell MUAs to highlight the signed parts.) If I were redoing it, I think I would go through all the advice and either turn it into a SHOULD if it tells you how to do more robust signing and verification, or get rid of it. If you recall my snarky message to Dave a few days ago, I actually do think we should get rid of that stuff. There are already a zillion ways to produce a technically valid but useless signature, so I'm not concerned about yet another one. I'd just like to give people who want to do useful signing and verification the best shot at it we can. Keep in mind the as if rule, which says that your code can do whatever you want so long as the results are the same as if you followed the spec. So if the spec says you SHOULD NOT sign or verify messages that have extra headers that MUAs are likely to render inconsistently, it would be entirely valid to have a validation prepass that ensured that the DKIM module never saw those messages at all. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
On 10/20/2010 04:36 PM, Steve Atkins wrote: On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote: Validating mail syntax belongs in the specification for the mail components and DKIM work belongs in the DKIM components. That's why, layer violation or no, I think it's important to distinguish between format errors that are likely to lead to misleading rendering in existing MUAs, and the much larger class that may produce nonsense but won't produce lies. I think we're close to converging here. I totally agree that that's an important distinction to make, document, highlight and shout from the rooftops. But... Does it *have* to use RFC2119 normative language? Here's maybe a better way to frame the question: Should we empower ourselves to label a DKIM implementation that doesn't do format enforcement as (a) non-compliant, or (b) low-security/low-quality? I'm pushing for (b), while someone who insists the text be normative is pushing for (a). I'm pushing for neither. It's not the DKIM verifiers responsibility to enforce that. I do think that an informative note observing Here are a couple of issues that might theoretically be exacerbated by a DKIM-using world; you might consider checking for these problems somewhere in your mail handling path, if you aren't already would be reasonable. Somewhere in your mail handling path might be in the same binary as the DKIM validator, or it may not - and implying that an implementation that chooses to handle two entirely separate validation issues in two separate modules is non-compliant or low-security or low-quality doesn't seem helpful. I think that Steve threads this just about right. No need to cast aspersions, or kick them off the compliant island. Just lay out the security consideration and let people deal with this however makes sense. I'm still puzzled how this tempest entered this tea pot. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
Michael Thomas m...@mtcc.com wrote: On 10/20/2010 04:36 PM, Steve Atkins wrote: On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote: Validating mail syntax belongs in the specification for the mail components and DKIM work belongs in the DKIM components. That's why, layer violation or no, I think it's important to distinguish between format errors that are likely to lead to misleading rendering in existing MUAs, and the much larger class that may produce nonsense but won't produce lies. I think we're close to converging here. I totally agree that that's an important distinction to make, document, highlight and shout from the rooftops. But... Does it *have* to use RFC2119 normative language? Here's maybe a better way to frame the question: Should we empower ourselves to label a DKIM implementation that doesn't do format enforcement as (a) non-compliant, or (b) low-security/low-quality? I'm pushing for (b), while someone who insists the text be normative is pushing for (a). I'm pushing for neither. It's not the DKIM verifiers responsibility to enforce that. I do think that an informative note observing Here are a couple of issues that might theoretically be exacerbated by a DKIM-using world; you might consider checking for these problems somewhere in your mail handling path, if you aren't already would be reasonable. Somewhere in your mail handling path might be in the same binary as the DKIM validator, or it may not - and implying that an implementation that chooses to handle two entirely separate validation issues in two separate modules is non-compliant or low-security or low-quality doesn't seem helpful. I think that Steve threads this just about right. No need to cast aspersions, or kick them off the compliant island. Just lay out the security consideration and let people deal with this however makes sense. I'm still puzzled how this tempest entered this tea pot. Um. That's not how I read what he wrote. He specifically said no to security considerations and I understand that's what you're in favor of. Confusedly yours, Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
On Oct 20, 2010, at 6:08 PM, Scott Kitterman wrote: Michael Thomas m...@mtcc.com wrote: On 10/20/2010 04:36 PM, Steve Atkins wrote: On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote: Validating mail syntax belongs in the specification for the mail components and DKIM work belongs in the DKIM components. That's why, layer violation or no, I think it's important to distinguish between format errors that are likely to lead to misleading rendering in existing MUAs, and the much larger class that may produce nonsense but won't produce lies. I think we're close to converging here. I totally agree that that's an important distinction to make, document, highlight and shout from the rooftops. But... Does it *have* to use RFC2119 normative language? Here's maybe a better way to frame the question: Should we empower ourselves to label a DKIM implementation that doesn't do format enforcement as (a) non-compliant, or (b) low-security/low-quality? I'm pushing for (b), while someone who insists the text be normative is pushing for (a). I'm pushing for neither. It's not the DKIM verifiers responsibility to enforce that. I do think that an informative note observing Here are a couple of issues that might theoretically be exacerbated by a DKIM-using world; you might consider checking for these problems somewhere in your mail handling path, if you aren't already would be reasonable. Somewhere in your mail handling path might be in the same binary as the DKIM validator, or it may not - and implying that an implementation that chooses to handle two entirely separate validation issues in two separate modules is non-compliant or low-security or low-quality doesn't seem helpful. I think that Steve threads this just about right. No need to cast aspersions, or kick them off the compliant island. Just lay out the security consideration and let people deal with this however makes sense. I'm still puzzled how this tempest entered this tea pot. Um. That's not how I read what he wrote. He specifically said no to security considerations I don't think I did. The informative note would probably be something informative, rather than prescriptive, in the security considerations section. What I wouldn't favour would be a MUST or a SHOULD or anything morally equivalent to either, as it's outside the scope of a DKIM specification to do that. and I understand that's what you're in favor of. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
-Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Wednesday, October 20, 2010 5:08 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] double header reality check Here's maybe a better way to frame the question: Should we empower ourselves to label a DKIM implementation that doesn't do format enforcement as (a) non-compliant, or (b) low-security/low-quality? The latter. Hey, we agree. I think I always said SHOULD rather than MUST. Damn, lost it. I think we should talk about it, and even in detail, but without using those words. And I'd be fine converting the MUA advice to which you refer into something more general, like hammering home the point about what exactly a validated signature is telling you, and leave it to the implementers of those modules to figure out what to do with that information. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
