Re: [ietf-dkim] DKIM Key Size Constraints
On Mon, 11 May 2015, Scott Kitterman wrote: > I propose a short draft that updates 6376 to say MUST use at least 1024 > bits and setting that as the minimum size verifiers must be able to > validate. I'm volunteering to write it if people agree it's appropriate. I don't see a benefit. Entities that simply do not use DKIM at all are a bigger problem than those that publish weak keys. And the fact that weak keys are presently legal does not provide a way to impersonate a sender who only publishes strong keys. The only point in specifying a limit at all is that it may allow shortcuts in implementation. I know the crypto library embedded in Exim fails (safely, but with an unhelpful error) if asked to sign a message with a key that is too weak. Since keys that weak are formally banned, it's not really a bug. (I noticed when attempting to re-use a YDK key I had already published. The format of the key in DNS is backwards compatible but YDK's recommended size was smaller than DKIM's minimum size.) And it's all irrelevant anyway in my view. There is currently only one accessory protocol for DKIM, and that protocol (DMARC) is even more useless than SPF in identifying mail to outright reject in-transaction. And that is the only mission I care about. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] That weird i= is most probably EDSP
On Mon, 12 Aug 2013, Roland Turner wrote: > I mean what benefit would a receiver enjoy over not implementing it at > all? It would be a spam filter basically. Being an anti-forgery protocol, it would have a high false negative rate compared to dedicated anti-spam techniques (since unforged spam definitely exists), but it would offer a very low false positive rate. Turning it on for all users by default would be even less controversial than turning on, say, Spamhaus ZEN. Except for the mailing-list-footers case and the traditional-forwarder case, no wanted mail is forged. And "EDSP" would not trigger on those two cases. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] That weird i= is most probably EDSP
On 22 Jul 2013, John R. Levine wrote: > >> "EDSP" would be tier 1 both senderside and receiverside. That's its > >> selling point. ... > > >> TPA ADSP enhancements are tier 1 receiverside and just-barely-above tier > >> 3 senderside. ... > > Did I miss some I-Ds describing these? TPA ADSP is Otis' baby, not mine. He has written drafts on it, although they are expired now. EDSP is just a concept at the moment. That's why I sayed "'EDSP' would be" instead of "EDSP is". Your question about drafts has two possible implications. The first is "I'm not going to pay any attention to Michael until he takes up RFC lawyering." In which case I can't help you. Another is that you just want a more concrete proposal to attack. So: My fantasy of EDSP is to have it as a new modifier to SPF records. This would avoid an extra DNS lookup when deploying it at a receiver that already checks vanilla SPF. Burying it in ADSP or DMARC wouldn't work as well, because then two lookups would be needed in the case that MAIL FROM: and From: differ. Only the direct SPF record for the domain would need to be checked - EDSP would ignore SPF redirections and includes. (Because of the connection to SPF, I've brought up ideas similar to this on spf-discuss years ago. Unfortunately they seem to be in a Not Invented Here mood regarding DKIM.) It would be a simple boolean -- either a sender domain has it on or off. If it's on, then a receiver site would be expected to enumerate through the DKIM signatures looking for a one that is both valid and where d= matches the MAIL FROM: domain. If none is found, then the recipient is strongly encouraged to 5xx the transaction attempt. (Obviously bouncing isn't a good idea.) Some people here seem to have a problem with the fact that the MAIL FROM: is not recapitulated in any header that DKIM can protect against alteration. I don't get why this would be a serious problem. It does mean you can replay a message with the MAIL FROM: altered, but you are still restricted to domains that have signed the message and cannot alter the body. I don't see the use to the bad guys. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] That weird i= is most probably EDSP
On Tue, 2 Jul 2013, Alessandro Vesely wrote: > > That's off in the weeds. EDSP would not take any notice of i=, and is > > not there to enhance SRS -- rather it's something of a competitor. (Both > > try to make return path validation work in spite of forwarding.) > > The point is what any of them might be useful for. It's about deployability. Many mail filtering strategies are not deployable widely even assuming the smartest possible mail admin and perfect MTA software. They require the cooperation of the end user in order to work properly. I classify the strategies into three tiers. On the first tier, you have things like Spamhaus ZEN, which can be deployed across all users at a domain, without any knowledge of the end-users habits. On the second tier, you have things like Distributed Checksum Clearinghouse, which require some information about the end-user's habits in order to work properly. For DCC and most other second-tier methods, this is a complete whitelist of their mailing list subscriptions. Without the whitelist, DCC will correctly notice that the mailing lists are bulk, and incorrectly assume that they are unsolicited bulk. On the third tier, you have things that require additional sacrifice (or great arrogance...) on the part of the user. One third-tier approach I personally use is blocking all HTML e-mails (including multipart/alternative). (I get away with that because I give any corporate entities I actually wish to hear from special canary-trap addresses that aren't so filtered.) Anti-forgery mail filtering methods are special in that they have separate receiverside and senderside components. Unless both components are present, they will always false-negative. (Note: below I'm counting "?all" SPF records as "not deploying SPF senderside", and ADSP/DMARC policies that do not recommend rejecting mail as "not deploying ADSP/DMARC senderside". Those configurations may be useful but don't facilitate an easy decision to reject an e-mail.) ADSP and DMARC are tier 1 on the receiverside and tier 3 senderside. Not many domains can make the claim that no mailbox in them participates in any mailing list. SPF is supposed to be tier 2 on the receiverside (needs a forwarder whitelist) and tier 1 on the senderside. SRS is a failed attempt to make SPF tier 1 on the receiverside. SRS's backers encouraged receivers to act as if it was already fully accepted and deployed, in order to pressure forwarders to cooperate or face false positives. But instead, this led many senders to avoid those same false positives by treating SPF as tier 3 on the senderside. A trick using VERPing (of which SES is a brand) can be used to make SPF tier 1 senderside again despite the damage done by SRS. That requires a special dynamic DNS setup, however. VERP also has a cost in that whitelisting is made harder for the recipient. "EDSP" would be tier 1 both senderside and receiverside. That's its selling point. The "dkim=except-mlist" ADSP enhancement I suggested back in 2011 would be tier 2 receiverside and just-slightly-below tier 1 senderside. It would not be obsoleted by "EDSP" or SPF, because when it can be deployed, it can stop some messages where From: is forged but MAIL FROM isn't. Although slightly less than ADSP or DMARC in the rare case that those are deployable senderside. TPA ADSP enhancements are tier 1 receiverside and just-barely-above tier 3 senderside. They could be as powerful as except-mlist in terms of false-negative rate where deployed at both ends, but require much more elaborate setup work at the sender. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] That weird i= is most probably EDSP
On Tue, 2 Jul 2013, Alessandro Vesely wrote: > So, if the bounce they get has text/rfc822-headers only, they [...] This is getting OT, but you can't even count on getting text/rfc822-headers in a bounce. I use Exim, a very popular MTA with the latest stable release just 8 months old, and it doesn't give MIME bounces *at all*. But back to EDSP: I still don't quite see how Return-path:'s special status is such a problem. I know that it's only generated from the envelope just before being written to the mailbox, and never appears in the SMTP transaction itself, and for that reason it cannot be *covered* by the signature. But it can still determine relevance. If you were to change the From: field of a message signed to pass ADSP/DMARC, you would make the signature bogus, and also make it irrelevant if the new address is in a different domain. If you change just the MAIL FROM: of a message signed to pass EDSP, you would make the signature irrelevant but not bogus. But I don't see how the above difference leads to any practical problem. I suppose a forwarder or other MITM could change only the left-hand-side of the MAIL FROM: and "get away with it". But why would they be tempted to do that? Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] That weird i= is most probably EDSP
On Tue, 2 Jul 2013, Alessandro Vesely wrote: > (subject adjusted) > > A sender using SRS would need to maintain a database of valid addresses. > [...] That's where EDSP can save the day. That's off in the weeds. EDSP would not take any notice of i=, and is not there to enhance SRS -- rather it's something of a competitor. (Both try to make return path validation work in spite of forwarding.) I'll note however that nothing done in the body or headers can bypass the length limits on VERPing (SRS being a subset). The whole reason VERPing is popular is because no one can count on a bounce message being in a standard format. You might get no recoverable information about what was *in* the failed message, but the MAIL FROM: is guaranteed to come back to you verbatim as the envelope RCPT TO: of the bounce. I just mentioned SRS as an innocent example of a message being relayed with verbatim body and headers but an altered envelope sender. And while that case could result in couple hundred bytes of wasted space in the header, it won't cause false-positives or false-negatives. So it's not worth losing sleep over. > It has to be in the message content for DKIM to be applicable. Core DKIM is only tasked with determining if a signature is genuine, not if the signature is relevant. Therefore it doesn't matter if part of the information EDSP uses to determine relevancy is out of band. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The problem with the DKIM design community
On Mon, 1 Jul 2013, Alessandro Vesely wrote: > Well, not really. MAIL FROM: is only visible after delivery, so to > avoid dangling signatures one should store its value in some other > header field or... in the i= tag. ITYM "only visible *before* delivery" There's long been a standard header for that purpose, "Return-path:". But EDSP checking in the MUA is not very useful -- if the Return-path is disavowed, then bouncing is an even worse idea than normal. The only place to act is in the SMTP transaction at the border. It does mean that if the mail passes through an SPF Sender Rewriting Scheme forwarder, then it will end up with an unbroken but irrelevant signature. Even if that forwarder knows about EDSP, it can't strip the signature because it can't know that it isn't there to serve a different accessory protocol yet to be invented. After all, most of the time MAIL FROM: = From:, so the signature added for the sake of EDSP will simultaneously be serving ADSP or DMARC. But I don't think that's a problem. The message will get through, because the forwarder now owns the MAIL FROM and it's up to him whether an EDSP check is needed. Also, if any DKIM accessory protocol will false positive OR false negative due to the presence of irrelevant (ie: not the d= you're looking for) signatures, then that accessory protocol is really broken. Of course, it's always correct for an accessory protocol to dismiss a message as "unsigned" if the irrelevant signatures the only signatures present. Any other behavior would fall under "false negative due to irrelevant signatures". Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The problem with the DKIM design community
On 23 Jun 2013, John R. Levine wrote: > But first you might want to look at some of the signed bounce address > proposals like this one, and consider why nobody adopted them. > [Link to SES] What I'm asking for is nothing like SES. I want the signature to be based on the envelope MAIL FROM:, but it is still the body that gets signed. No VERPing is called for. My protocol would have almost the same mailserver behavior as ADSP, except that where ADSP only pays attention to signatures where "d=" matches the right hand side of the RFC822 From:, my "EDSP" would only pay attention to signatures where the "d=" matches the right hand side of the RFC821 MAIL FROM:. This means that someone can publish the strictest possible EDSP without causing mailing list false positives. Mailing lists take ownership of the MAIL FROM:, hence only an EDSP set by the list itself will apply, and the original poster's EDSP will be correctly ignored. Just like in SPF. Of course, since the MAIL FROM: is usually not visible without pressing a "show all headers" button, this would be more about leaving a clearer audit trail than actually foiling phishes. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] The problem with the DKIM design community
On Tue, 18 Jun 2013, Douglas Otis wrote: > Trust in a DKIM signature is being used as a basis for acceptance as > described in section 5.4 in [RFC5863]. Since neither SMTP nor DKIM check > for invalid prefixed header fields, TBTB domains offer a simple means for > malefactors to have their deceptive messages delivered to their victim's > inbox. This problem is real. Ukh. This again. I think I see what the problem is with the DKIM design community. Most of you assume that once DKIM and an accessory protocol of choice (DMARC, etc.) reaches a sufficient amount of respect from the RFC machinery, it will magically be deployed absolutely everywhere it is relevant. Otis is just a shade more humble. He thinks the magical deployment will occur, but will be accomplished by a jerk literal genie, who will try to pass as much bad mail as possible while keeping to the letter of the final DKIM spec. In reality, the recipient end DKIM deployment will be driven by sysadmins representing end-users who want less bad mail to reach them. Unlike the participating senders, they are not afraid of a phish or virus mail succeeding --- they merely do not want to be disturbed unless the mail is actually relevant. (So if Otis' attack actually gets used, it will be in the selfish interest of those domains to filter it, there being no legitimate use for double From:s. SpamAssassin would likely pick it up, resulting in sites that block the attack mails while not even using DKIM.) The accessory protocols I've seen are unusable senderside even by my vanity domain, let alone casual users, because of the mailing list problem. Those who believe in magic deny this is a concern, because despite the fact that we represent the vast majority of senders, we aren't "phish targets". But if extra context is only provided for the tiny fraction of mails purportedly from "phish targets", then DKIM isn't worth my while to deploy receiverside. (I have deployed DKIM alone senderside, but that's just to keep in practice in case someone invents an accessory protocol that's actually sane. Allowing me to declare that all mail bearing my RFC821 MAIL FROM: without a corresponding signature is bogus while saying nothing about that which merely bears my RFC822 From: would be a good start.) Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,
On Fri, 12 Aug 2011, Douglas Otis wrote: > The outcome in either "except-mlist" or "all" remains beyond the > sender's control. "except-mlist" is no worse here than "unknown", which is what the vast majority of domains will be publishing in the absence of the "except-mlist" option. > The sender benefits so let the senders do the work. A win-win for both > the sender and the recipient. For most domains, the sender benefits are not sufficient to motivate a "discardable" or TPA deployment. And with neither TPA, "discardable" nor "except-mlist" in common use, paying attention to ADSP isn't worth an MX admin's time. The sender loses utterly. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,
On Mon, 8 Aug 2011, Douglas Otis wrote: > The concept behind the TPA scheme was to enable services on behalf of > senders that lack requisite staffing to support this level of policy > effort when using open-ended third-party services. The list of open I don't see how that can work anytime soon for the use-case that concern me, that of ordinary end-users at a consumer ISP posting to mailing lists. I suppose you could implement a central whitelist of mailing lists, but some mailing lists are easier to forge than others. If a weak mailing list gets on to the whitelist, then you have a policy just as easy to bypass as except-mlist. But if a mailing list *that people actually use* can't get on the whitelist, you have false positive rejections. > Why should white-listing mailing-lists or open third-party services > become a burden for the recipient or their administrator? Better I'm not seeking to *impose* that burden as a sender, I'm looking for the opprotunity to *accept* that burden as a recipient, so as to reduce my incoming false negative rate. Many recipients can't take up the burden, and thus cannot detect forgeries of except-mlist domains. But they lose nothing compared to the world with just "unknown" and "discardable". (I'm not counting "all" since it is too vague...) Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,
On Mon, 1 Aug 2011, Douglas Otis wrote: > This would be a safe method to extend policy without requisite two > party coordination as currently expected by DKIM. The problem is that for the majority of From: domains claimed in incoming mail, the TPA approach is just as unfeasable as "two party coordination". The problem is not the lack of a language for the alleged-sender to express detailed policy -- it is that the alleged-sender doesn't have a fully detailed policy to express. The real communication barrier is between the DNS admin for a domain, and the end users who have mailboxes on that domain. An end-user would have to be exceptionally computer literate in order to help his admin publish a correct TPA policy. While *phishers* may see no point in forging that class of domain, a layered protocol (ADSP or successor/replacement) that makes no attempt to defend those domains is not worthwhile for me to deploy *as an MX admin*. Which means blatant phish with a single From: and no signature could sail right through. The best that the administration of such domains can offer, is a claim that the end-users have been trained to always use the official smarthost, and thus every non-mailing-list mail will be signed. It's weak, but it's far better than nothing. For some recipients, such as myself, it would be as useful as discardable. I know that anything that smells enough like a mailing list to invoke the loophole, yet hasn't already been diverted by my whitelists, is junk. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,
On Wed, 27 Jul 2011, Douglas Otis wrote: > DKIM should be viewed as a Work-In-Progress still missing a viable > policy layer. So you at least agree ADSP needs reform or replacement. Here's another way to express my points. Of the policies a sender may wish to publish in ADSP or a successor, some are worthless or nearly so for the purpose of preventing phish sent in the name of that sending entity. "dkim=unknown" is of course such a policy, and so is my "dkim=except-mlist". I imagine TPA could be used to write an infinity of such policies, as well as solid ones. But such policies may still be useful in the big picture. If a sender is not a bank, perfect forgery protection is not needed, and likely not worth the sacrifices required for a solid policy. But such senders may be able to provide information stronger than unknown, yet weaker than discardable. It's good for the phish targets if those domains do. At present, admins seem in no hurry to develop and deploy receiverside ADSP support, since it is rare for a domain to deploy discardable, and thus even rarer for ADSP (as-it-stands) to ever make a reject recommendation. If most domains published -at least- a weak policy, receiverside ADSP deployment would become worthwhile. If except-mlist became standard, a BOFH might implement ADSP for his own account, and he would see a decent reduction in overall false-negative rate, because after applying his mailing-list whitelist, he can treat except-mlist as discardable. He can't do that for his users (as he does not know for sure what they are subscribed to), but once he's taken that first step, it's easy for him to treat except-mlist as unknown for them while *still respecting discardable*. And the phish targets will then be happy to see discardable honoured. Consider SPF. SPF does nothing to prevent phish, as it only protects the MAIL FROM: address which is not presented to the user by default. Yet receiverside SPF deployment has progressed further than ADSP, because SPF does kill some spam. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,
On Wed, 27 Jul 2011, Douglas Otis wrote: > Your fix will not control phishing or spoofing abuse and would expose > these domains to open-ended sources. ADSP reforms along my lines would not create any additional exposure, because they are only intended for senderside deployment by sites that are currently entirely naked. The availability of weak ADSP declarations would actually increase the protection afforded by "dkim=discardable", because then fewer domains would go without ADSP, and more MX administrators would be incentivized to implement and arm it. Remember, for an MX admin the goal is not to "control phishing". That's just a side benefit of their true goal, to "control forgeries". When forgery can be reliably detected, it becomes a low-false-positive noise filter, something every MX admin loves. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,
I have one comment to make which ties together both my stance on Otis' doublefrom crusade, and some reforms I have argued for in ADSP. Basically, at present the doublefrom trick is simply *unnecessary* for someone trying to pass me a forged mail. My MTA, Exim-4.76, does not natively support ADSP. It does support core DKIM, but without ADSP it's not reasonable for the DKIM result to have any effect on the message disposition. It probably wouldn't be *that* hard to cobble together some receiverside ADSP implementation using Exim's other features, but it's just not worth my while. I'm not afraid of any phish fooling me, but I am interested in anything that reduces the amount of "bad mail" reaching my inbox. But while a lot of spam is forged, it's forged to be from some ordinary schlub, not Paypal. I keep records going back to 2007, and since the start of that year 254 bad mails (spam and viruses) have gotten through to me. They represent 210 alleged From: domains. Of those domains, -absolutely none- of them, -today-, have ADSP records at all. Not even a "dkim=unknown"! Thus retrospective analysis shows ADSP is unlikely to make any difference. I may well implement double-From: detection alone. *It* would have blocked three spams from that interval (none of which bear any attempt at a signature). Now, all that aside, Paypal would probably still really like me to arm ADSP, just in case. But while it may be worth *their* time to sail 100km to meet me (that is, by actually maintaining no-mailing-list discipline so they can use discardable), it's not worth *my* time to drive 1km from my hilltop home to the port to meet them. If ADSP were fixed so that it could be deployed meaningfully at ordinary domains, with users who post to mailing lists, this might change. I've already stated my fix -- add "dkim=except-mlist", which states that any message with broken/absent signatures should be considered bogus if it is known not to be a mailing list message. While merely adding a fake "List-Id:" header might let forgeries of except-mlist domains get through to many users, that will never work on me. I recognize my mailing lists via other indicia that are harder to forge (the MAIL FROM:). Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Doublefrom language should be in ADSP, not core
On Sun, 10 Jul 2011, Hector Santos wrote: > Well, you have a point: > > DKIM has failed to address legacy spoofing problems. That's not quite the point I intended to make. I consider it faintly possible that a situation could arise where a lazy validation module embedded in an MTA always checked the last of multiple Froms:, while an MUA always displayed the first From: -- or vice versa. But I find it very unlikely that a validation module embedded in the MUA itself would be vulnerable. It might fail to notice double Froms:, but it will validate the same one it shows the user. So it will either sound the alarm, or say "correctly signed" while ignoring the address the forger wanted the user to see, showing his own domain instead. Now, unless the MTA is *so confident* that a signature should have been there that it *refuses to deliver* suspect mail, its validator doesn't have an effect on the end-user. And such confidence isn't likely without use of a layered protocol, ADSP being the only one published yet. Thus, if the user has no validator in his MUA, for now it's just as if DKIM didn't exist. Doublefrom can't buy the forger anything more. If he does have a validator in his MUA, then he is unlikely to be vulnerable. (and that doesn't even consider all the fuss we've made here about this angel on a pinhead...) Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Doublefrom language should be in ADSP, not core
On Sun, 10 Jul 2011, Hector Santos wrote: > Now of course, if ADSP was a standard and whitehouse.com had an > exclusive signing policy, receivers would of rejected the junk > distributed by Dave's list server as an ADSP violation. But ADSP is a > pipe dream. The attack only matters if the user believes that forgery is impossible because his ISP and the putative sender both "deploy ADSP" -- and thus the fact that the message made it to his mailbox means it has to be validly signed. (Of course, such users are suckers for messages from "0bama"...) Otherwise, "Obama" messages with an alternate From: (which the forger hopes the MUA will ignore) and signature for that second From:, are no more convincing than plain old forgeries with a single From: and no signature at all. In fact, they can be less effective, since: 1. At any step on the way, the message may be rejected as a protocol violation. 2. The MUA might display to the user, the From: instance that was intended by the forger for the validator's eyes only. 3. The lazy validator might act on the From: instance that was intended by the forger for the MUA to display. Failures (from the forger's perspective) 1 and 2 produce a result less convincing than a simple unsigned forgery. Failure 3 produces a result no more convincing than the simple unsigned forgery. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Doublefrom language should be in ADSP, not core
One additional thought on the whole double-From: argument -- if RFC
language on the issue is justified at all, it really belongs in the
ADSP RFC, not a core DKIM one.
A double-From: doesn't even rise to the level of theoretical threat
except when dealing with ADSP (or a successor).
If we, for example, invented an "LDSP" protocol to allow mipassoc.org to
assert that any message bearing "List-Id: ietf-dkim@mipassoc.org"
without a d=mipassoc.org signature is highly suspicious, then the
operation of that defense would be entirely unexploitable by
double-Froms.
Of course, a lazy "LDSP" might be exploited with multiple List-Id:
headers, and that would actually be more significant. List-Id: was
invented after RFC822, so we can't claim multiple copies of it violate
the protocol.
To the core DKIM spec, "From:" isn't magic at all. Rather than
enumerate every header that might be sensitive, we should put in a
non-normative note that layered protocols should consider the issue:
{
Most expected applications of DKIM will involve signatures added by a
sender in order to justify their use of a name in some other header of
the message. For example, ADSP allows a domain to assert that
their signature must be present for a message bearing one of their
addresses in the From: header.
It is suggested that such layered protocols include an explicit
requirement to check for multiple copies of whichever header they
defend. Otherwise, a situation could arise where a lazy validator
approves a message based on all appropriate signatures being present for
just one instance of the header, and yet a downstream entity falsely
assumes a different instance was so validated.
}
Michael Deutschmann
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Final update to 4871bis for working group review
On Wed, 6 Jul 2011, Barry Leiba wrote: > As Pete has pointed out -- and has he's adamant about -- the signer > can't attack... that is, DKIM can't do anything about "attacks" by the > signer. Under the double-From: exploit Otis is so concerned about, one signer can (given favorable winds) trick an end-user into thinking his message was signed properly *by someone else*. So indeed, a signer can attack. Although I still don't agree with Otis' demands for extra language in the RFC. Really, his case would make sense if there was some squad of thugs ready to force every mail-admin to implement DKIM, but only to the strict letter of the final RFC. Then putting that in might make a difference -- but so would throwing in a whole bunch of other unrelated anti-abuse best practices. In real life, however, if you don't have the power to demand that a recipient mail admin block incoming double-From: messages, then you don't have the power to demand that they deploy DKIM at all. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] spam filtering 101, was DKIM expert group meeting , for Dutch 'comply or explain' list
On Fri, 24 Jun 2011, Dave Crocker wrote: > Let's simplify this discussion: > > Spammers do a variety of techniques to trick filters and users. > > We should have the DKIM signing specification normatively require > checking for every known technique, since we cannot be sure that any other > part of the system will perform the necessary checks. Leaving aside the fact that Dave is kidding above, for those who think that is a good idea on it's face, I'd like to reiterate my suggestion for this problem: * Put it in its own RFC * I think there's room for a "Minimum Quality of Forgery Supression" BCP. Such an RFC would outline a number of faults a message can have, and declare that any of those faults mean the message MUST NOT be delivered to the nominal recipient. ISPs would then promise to follow this RFC, and in return phishing-sensitive institutions may reward users who give contact addresses at a compliant ISP, such as an exemption from a "phishing insurance" fee. To be actually useful, such a standard would need to reach beyond DKIM and ADSP. For example, some sort of means to prevent full-name abuse (Paypal ) or mispellings () would be vital. Those are hard problems, the DKIM people should not have to be weighed down working on them. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On Mon, 30 May 2011, Steve Atkins wrote: > The most obvious thing that MLMs do that invalidate signatures are 1. > append content to the body and 2. prepend content to the subject line. Any > approach that allows me to replay messages while making those changes > seems to open the door to abuse. Look at the big picture though. It is true that once spammers adapt to it, a weak signature that tolerates appended body text and a mutilated subject will have an atrocious false negative rate. But, right now we have a 100% false negative rate for purported senders who use mailing lists, since such senders will not publish dkim=discardable. A loose signature can only improve things. Also, there's another way a weak signature could be helpful, even if it was *so* weak that it forgives any message mutilation other than to the To: and Cc: headers: My mailserver is programmed to refuse blind carbon copies (with exceptions for the mailing lists I subscribe to). If a forger attempted to lurk on a mailing list and then replay the shortest message he sees there with his spam appended, he still won't be able to reach me, since the To: header will contain that list's submission address, and not my address. (If he used a list I subscribe to, he still loses. My exceptions are keyed on the MAIL FROM:, and SPF guards that.) Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 23 May 2011, John R. Levine wrote: > Seems to me that if someone were that desperate to get a signed message > through a downgraded path, they should wrap the whole thing in a > base64 encoded message/rfc822 mime part and send it that way. That's explicitly forbidden by RFC 2046. Some idiot lazy MUA writer sought a guarantee that his MUA would be able to look inside forwarded-as-attachment mail without having to handle multiple layers of encoding. He got it. Thus, no multipart or message/rfc822 object can be base64 or QP encoded. Because of that arrogant decision, a downconversion for a message containing a message/rfc822 element under 8bit CTE (which *is* legal), simply isn't defined. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On Thu, 19 May 2011, Murray S. Kucherawy wrote: > The presented argument, which comes from an IETF outsider involved with > MTA development, is whether or not that SHOULD is worthy of a MUST because > failing to do it in the vast majority of cases will result in a downgrade > somewhere on the path that will invalidate the signature. The question, > then, is why we didn't do MUST in the first place. It's a perfectly > legitimate question. One suggestion for compromise, from another "outsider" (myself): Specify MUST, but clarify that this is just for now and may be revisited at a later time -- for example, if the SMTP protcol design community ever backs down and accepts DJB's approach to the 8-bit message problem (<http://cr.yp.to/smtp/8bitmime.html>, essentially that it is OK to break any remaining 7-bit enforcing servers). They probably won't ever, but just in case... So then there would be also a MUST that *incoming* 8-bit DKIM-signed messages be processed in the obvious way. This would never be used in the present, but allow future protocol designers some leeway. By the way, note that DKIM is not alone in this. S/MIME (RFC 1847) says, on page [4]: # In addition, if the multipart/signed object is EVER to be # transferred over the standard Internet SMTP infrastructure, the # resulting MIME body is constrained to 7 bits -- that is, the use # of material requiring either 8bit or binary # content-transfer-encoding is NOT allowed. Such 8bit or binary # material MUST be encoded using either the quoted-printable or # base64 encodings. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements
On Fri, 22 Apr 2011, Hector Santos wrote: > So presuming there is a discovery method lets say for ISP/ESP domains > with ADSP Checking Support, gmail.com users will have a bank surcharge > and hotmail.com will not? If Hotmail always respects dkim=discardable and Gmail ignores it, then yes. > It will depend on what authorized signer (SDID) the bank will select. This paragraph was a little too jargon thick for me to process fully. However, I suspect you're getting at the fact that, if it had to be written today, such a certification standard would be hamstrung by the fact that ADSP sucks. All it could do is make dkim=discardable *binding*. Since a bank that wants the freedom to have their employees speak ex-cathedra on ordinary mailing lists cannot use discardable, they would not be able to take advantage of the phishing protection. Obviously then, writing an improved ADSP-alike protocol is higher priority than writing the certification standard. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements
On Mon, 18 Apr 2011, Douglas Otis wrote: > One method to avoid look-alike or display-name attacks would be to sort > messages into folders. A fairly common practice. Users with the technical acumen to do such sorting are unlikely phish victims. They might not immediately recognize a message as forged, but will instantly become suspicious if asked to "re-enter" passwords. Once they detect such a phish, they may be annoyed, but they can then implement a double-From: filter to drop future attempts on their own, without needing an RFC to tell them so. > From header field checks during signature validation would permit > simplistic phishing attacks not controllable by the domain being > phished. :^( Phishing attacks are *never* controllable by the domain being phished. Nothing forces an ISP to deploy receiverside ADSP at all. To change that, you need to invent some sort of certification for ISPs that they take reasonable steps to prevent forgery. Then banks could impose a "phishing insurance" surcharge on any user who provides a contact address at a domain that is not certified. An explicit requirement to reject double-froms would be appropriate in the standards for such a certification, but not in the draft at issue. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements
On Fri, 15 Apr 2011, Douglas Otis wrote: > In addition, verifiers MUST > ensure the presence of multiple singleton originating header fields > do not provide a valid signature result. > --- > > Not including this additional requirement removes recipient assurances a > sender may have expected to be offered by DKIM. Not... This... Again... There are already other ways to get a phish past an unsuspicious user in spite of DKIM/ADSP. The full name trick is one, mi5pe11ings are another. Also rather important is that few users are likely to have the thing armed to block mail. You're basically trying to weatherstrip a barn door that we have no idea how to even close. Pointless. (Also, the extra filtering you want would quickly be added to SpamAssassin anyway, once people try to exploit it.) Requirements to strictly enforce the message format do have a place, but in a different RFC. Such an RFC would outline minimal standards for supression of forgeries. Email providers who follow this hypothetical RFC would advertise that fact, and then phish-target sites might reward users who provide a contact address at a compliant site. But you'd need to put a lot more than just a reference to ADSP and your enforcement of a unique From:, to make such a document viable. Otherwise phish-targets won't offer sufficient reward to be worth the tech-support hassle of being unable to disable ADSP (lest they lose compliance) at the request of a user with a false-positive problem. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the alleged list problem, was If DKIM would ignore
On 5 Apr 2011, John Levine wrote: (> > = me) > >We'd like to be able to deploy DKIM, coupled with some ADSP-like protocol > >(The real ADSP is hopelessly inadequate) in order to block all forgeries at > >the MX. *All* forgeries, not just phish. > > Well, as we've established long past the point of boredom, you can't. > And it's not just mailing lists. Don't forget all the mail that bots > can send with real stolen credentials, Small semantics issue here. You are using a vertical "all" (eg: "With this ADSP-alike, it will be beyond impossible for a @paypal.com mail to get through that is not sanctioned by PayPal's legitimate officers."). But I meant a horizontal "all" (eg: "With this other ADSP-alike, @paypal.com forgeries are reasonably expected not to get through, and neither are @gmail.com forgeries or @iecc.com forgeries."). By stating "all", I was distancing myself from those here who consider it Not A Problem that Gmail is never going to deploy "dkim=discardable", since Gmail is "not a phishing target". > and mail to a friend, blah > blah. (This is not an invitation to reargue those points.) There is a difference in kind between mailing lists and all other "friendly forgery" cases such as F2F. Providers of F2F will likely give up and use original From: addresses before end-users give up and (force their BOFH to) undeploy ADSP. But the mailing list problem for ADSP is even bigger than SPF's forwarding bugaboo -- it utterly scares off meaningful senderside deployment. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the alleged list problem, was If DKIM would ignore
On 31 Mar 2011, John Levine wrote: > Quite right. It would be helpful to me if people could explain what > problem they're trying to solve when they bring up mailing lists yet > again. "Some lists break submitters' signatures" is a fact, not a > problem. "I am trying to do X with my list mail, but I can't so I > have to do Y instead" would be a problem. Isn't it obvious? We'd like to be able to deploy DKIM, coupled with some ADSP-like protocol (The real ADSP is hopelessly inadequate) in order to block all forgeries at the MX. *All* forgeries, not just phish. And I emphasize this should be automatic -- suspect messages should be rejected, not merely highlighted so the user can decide whether the signature breakage was innocent. But the fact that most actual users post to mailing lists and obviously do not want those posts blocked, coupled with the fact that the mailing lists break signatures, means that the obvious implementation would have an unacceptable false positive rate. So we need to make a hole -- hopefully as small as possible -- in our ADSP-like protocol so that mailing list traffic can get through. Otherwise no one will deploy it in a useful way. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Full name problem
On Wed, 2 Mar 2011, MH Michael Hammer wrote: > This relies on the user having the entries in the address book. As many > marketers would tell you, easier said than done when it comes to > corporate/organizational mail. I can't speak to mail from individuals. The mail wouldn't be blocked -- it would just be presented to the user with only the raw computer e-mail address. This might annoy a company's branding ambitions, but it wouldn't be fatal. (This means that the phish-preventing effect still counts on the user realizing that a mail bearing, say, a @hotmail.com domain is unlikely to speak for PayPal. All it does is make him more likely to notice by removing the distraction of an exactly-as-expected full name.) Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Full name problem
On Tue, 1 Mar 2011, MH Michael Hammer wrote: > The display name is problematic as Mr. Crocker has pointed out. One > solution to this which I have suggested in the past is to not display > the display name in the MUA if the email fails to authenticate. That won't help. The attack mail will authenticate successfully -- the attack hurts because the identity the *computer* thinks it was expected to verify is not the identity the *human* thinks has been verified. Both the double-From: and the Full Name attack rely on that principle, but the double-From: is less of a threat. Since double-From: is based on a protocol violation with no history of accidental use, it can be blocked with no false positives. (Also, there's a half a chance the MUA will display the From: the attacker intended only for the validator, to the human.) To fix this in the MUA, I'd have it strip the Full Name from *all* messages, then re-insert the Full Name as listed in the user's address book if there is any match against the real address. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Full name problem
On 27 Feb 2011, John Levine wrote: > Um, you must be new here. We've argued about this ad nauseam > over the years. I've been subscribed since Janurary 2008. Although my eyes may have glazed over during some of the longer threads There are two uses for a protocol similar to DKIM/ADSP. #1: it can be used as one of many general mailbox decluttering weapons, reducing the amount of "bad mail" of various sorts that the end recipient has to sort through with his own eyes. #2: it can be used to stop phishes from being successful, by preventing gullible users from even seeing them. The immediate responses I'm getting in this thread suggest the intended mission of DKIM is #1. Which is what I thought in the very first place, as the Full Name Problem makes mission #2 rather problematic. And yet, two things on this list seem to indicate that there are people here who think #2 is the mission: First, there's the whole double-From: fuss. The demand for coercive language on this minor point only makes sense on the assumption that the recipient admin is not eager to block suspect mail; that he is only implementing ADSP for some sort of Good Netizenship ticklist. Second, one of the responses I've gotten to my "except-mlist" proposal is that the domains for which it would be superior to TPA (consumer ISPs, basically) are not phish targets. That is true, but it is only a counterargument under mission #2. Under mission #1, it is just as valuable to block *@gmail.com forgeries as *@paypal.com forgeries. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Full name problem
There's one problem with DKIM as a phishing defense, which I have mentioned in passing a few times here, but no one else seems to have taken up discussion of. An e-mail From: usually has two parts. One is the email address itself. The other part is the full name of the sender. Usually the address is enclosed in angle brackets while the remainer of the header is the full name, although there is an alternative form where the full name is in parentheses and the address is bare. Full names are not used in routing and not registered anywhere. Neither DKIM nor anything else can validate them. Nonetheless, in summaries of incoming mail, MUAs tend to display *just* the full name. Hence, I could send a phish as: "From: PayPal " and (so long as the content was good enough) fool an unsuspicious user while passing ADSP with flying colors. An already-suspicious user could see through it -- but such a user would probably look at the other headers and notice anomalies without needing the help of DKIM. All ADSP would do is help declutter his mailbox of the forgeries that don't use this trick. By the way, this is why I consider the double-From: problem to be a molehill. If widely used, the double-From: would quickly appear in SpamAssassin and the like -- one doesn't even need to do any cryptographic work to detect and block it. In contrast, detecting false full names would require some sort of registry that does not exist at present. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
IMHO, a user who would be fooled by your: > From: President Obama > From: Hector Santos would also likely be fooled by: > From: President Obama The latter problem is a hole DKIM just can't plug. At least the dual-From: trick is an easy signature to add to a content filter. By the way, there is no whitehouse.gov ADSP record, so a simple first person forgery of Obama with no trickery would pass today. Although the forger would be wise to use his own MAIL FROM:, as they do have SPF. Being constructive, recommendations such as "don't allow multiple From: -- if you really have to then *at least* act on the least favorable ADSP result for each address" should probably go into a seperate document, likely a BCP. We could probably fill a document with other recommended techniques an ISP could use to help protect banks from the gullibility of their users, including techniques outside the scope of DKIM. Such as any kind of stab at solving the human-name problem I've highlighted (but that's a huge can of worms), or suppression of attacks using lookalike domains. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On Tue, 28 Sep 2010, Steve Atkins wrote: > Putting it in the List-Unsubscribe header that's not displayed > to recipients is pretty much equivalent to putting it in the X-Bamboozle > header that's not displayed to recipients when it comes to displaying > legally required content to recipients. And there's the rub. The problem is that a major threat we anticipate, is that should a means be added to append a footer without breaking the signature, bad guys will find short legitimate messages and replay them with a footer containing spam. Requiring the list garbage (and thus the spam) to be in X-Bamboozle: headers would make this problem far less likely, since forgery recipients would not likely see the spam. But as you say, it is not adequate for the lawyers. They demand the same visibility a spammer would want. DKIM has the unfortunate problem of coming late to the party. If DKIM had got there first, before it became near universal to add footers, mailing lists would have been faced with unacceptable delivery rates when they tried, and it would be seen as completely *their fault*. If the lawyers did persist, all the list-managers could do is shut down until all their clients hand over their keys But DKIM presently has the lawyer's car parked in front of its driveway, and can't complain because that car parked before the house was built. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On 27 Sep 2010, John R. Levine wrote: > I hadn't realized how many medium-sized MTAs do their DKIM during the > SMTP session. You learn something new every day. It still sounds like a > design that *requires* that an MTA do DKIM at SMTP time would present a > problem for some mail systems too large to ignore. If DKIM and ADSP had been invented ten years ago, perhaps post-transaction validation would have become the norm. But some time ago, spamfighters (who have been driving MTA software innovation) became deeply troubled by the fact that content-level spamfilters such as SpamAssassin could only be used in a way that either generates backscatter or causes false-positives to simply vanish. So, by lobbying and contribution of coding effort, they've pushed the dominant MTAs to structure themselves so as to be able to do significant analysis during the moment between CR LF '.' CR LF and its reply. It does break the intent of the RFCs, which expressly demand minimal delay at that juncture to avoid duplicate messages, but we don't care. Duplicate messages are far less horrible than backscatter. Anyhow, with that infrastructure in place, DKIM checking is trivial. At least message hashing can be streamed. We don't need to wait until CR LF '.' CR LF to *begin* analysing. Oh, and in any ADSPbis, I would like to see a flag that forbids silent discard but permits in-transaction rejection. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On 2010-09-27, John R. Levine wrote: > And since this group seems to be obsessed with arcane corner cases, > what do you do with a discardable message if it's sent to two addresses, > one of which is a mailing list and one of which isn't? That's a trivial specific case, of a general problem important in spamfighting. While a perfect solution would indeed require an extension to SMTP, we have ways to approach it. (Basically, give 4xx's at RCPT TO: when about to accept mail to boxes with divergent filters. But since this delays mail, when possible just merge the competing filters into one common denominator, accepting possible "overblocking".) But it's not even a problem for modern mailing lists. They can afford to send a "bounce" message in this case, as they already have a confirmed opt-in communication channel to talk with their subscribers. It wouldn't work out if a non-subscriber posts to the list, but for other reasons, modern lists make it a requirement to opt-in subscribe and then suspend delivery, should one want to post without reading. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On 27 Sep 2010, John R. Levine wrote: > > A reasonable interpretation of the RFC is that "dkim=all" still indicates > > that all mail with no signature is bogus > > No. If that's what we meant, that's what we would have said. I base that on section B.1, which specifically mentions mailing lists as a possible contraindication to "dkim=all" use. And, last year (2009-10-10), you said: > People who contribute to mailing lists shouldn't say dkim=all. We > argued this ad nauseam when we were hammering out ADSP, it shouldn't > come as a surprise to anyone. (which is what lead me to propose except-mlist in the first place.) So if "dkim=all" is: * not suitable for senders who are as confident in their signing as "dkim=discardable" users, but do not approve of discarding mail without a bounce. * not suitable for people who sign all first-party mail but post to legacy mailing lists. ... then what the heck is it good for? Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On 26 Sep 2010, John R. Levine wrote: > No, of course not. I've already adjusted my list software to put DKIM > list signatures on outgoing mail. It was no big deal. I haven't done > anything with ADSP because, to several decimal places, nobody uses ADSP. I was suggesting the From: hackery as a substitute for preemptively blocking ADSP-using posters, not as a substitute for adding a List-Id: signature. Although without an "LDSP", List-Id: signing is almost pointless. To benefit, you need to tell the recipient, human-to-human, that your list always signs. But if that communication channel is open, you could just promise not to change the bounce-address domain, and protect that domain with SPF. > What have you done on the lists you run? I don't run any lists. One other important thing: While preemptively blocking "dkim=discardable" is reasonable, to definitively avoid DKIM false positives you must also restrict "dkim=all" posters. A reasonable interpretation of the RFC is that "dkim=all" still indicates that all mail with no signature is bogus -- the difference from "discardable" is that the latter indicates the sender is willing to accept that suspect mail may be silently blackholed (thus making diagnosis of an FP-causing configuration error harder). So an MX capable of validating before responding to CR LF '.' CR LF may treat them identically. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On 24 Sep 2010, John R. Levine wrote: > Good point. So it's two things, lists should sign outgoing mail, and > discard any incoming mail with dkim=discardable. One thought - If lists are going to spend any time paying special attention to DKIM, it would be easier for them to just always rewrite the headers like so: From: Joe User becomes From: Joe User (i-use-discarda...@example.org) And thus avoid any problems no matter what the original sender's policy is. (Ok, it will silently break take-address-from-message features in the mail client. Adding a Cc: header listing the original From: address would help with that.) The fact that this would work brings up a separate flaw in DKIM that I believe has been mentioned before. There's not much of a solution to it, though. ---- Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On 24 Sep 2010, John R. Levine wrote: > Since RFC 5617 says that discardable domains should not send mail to > lists, nobody who can read should be affected by that. But that means DKIM/ADSP gets deployed so rarely at the sender side, that it could just as well not exist. And that still leaves the problem of dkim=all. > Hmmn. I'm not sure what you're talking about here, but since neither DKIM > nor ADSP say anything about "relevant" signatures, it can't be either of > them. I meant "relevant to ADSP" -- that is, specifying a key in the domain of the From: address. Everything else is irrelevant to ADSP, although it is explictly defined that such signatures are just ignored since they may have meaning to other protocols layered on DKIM. We can't just modify ADSP to allow all messages where *either* From: or List-Id: have a matching signature, since that allows anyone to bypass the intent of ADSP by creating a rogue list. Combined with a whitelist of List-Id:s to accept in lieu of a valid From: signature, "LDSP" would be quite secure. But the whitelist is pretty good on it's own. An armor analogy: Whitelist of mailing lists to which one has actually subscribed = Chest Plate A hypothetical revised ADSP with "all" clarified and an "except-mlist" option. = Leggings and codpiece A hypothetical "LDSP" = Gauntlets and helmet ADSP as it stands = A magic impenetrable sleeping bag TPA = a full suit of cloth armour You need the plate to protect against evil opt-out "mailinglists". You need the leggings to protect against ordinary forgeries. And you in theory need the gauntlets to stop forgeries of mailinglists you do trust -- but in practice that attack is rare. TPA gives good coverage, but most attacks -- those that pretend to be from ultimate senders who didn't have the inclination to deploy the thing, will go straight through. The bag is guaranteed to keep you alive, but you'd be a fool to use it in battle. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
> On 23/Sep/10 21:16, John R. Levine wrote: > > All of this emphasis on complex designs for MLMs strikes me as a waste > > of time, since it's a tiny corner of the mail space that has not > > historically been a vector for abuse, and shows no sign of becoming one. It may be tiny, but users will not tolerate the total destruction of mailing list traffic, which is the inevitable result of any ADSP use at both ends which is sufficent to block actual forgeries (without using whitelists). > > That's why my advice is that lists should sign their mail, which is > > easy and at worst harmless, and we're done. It's easy but useless, since the MLM doesn't have the private key needed to create a *relevant* signature. Inventing an "LDSP" to allow lists to indicate that certain List-Id:s are always associated with signatures would not be a total waste of time. But it cannot solve the "mailing list problem" alone, because the badguys would do their mischief using "lists" with List-Id:s in domains they control. They'd have the private key, so their bad-mails would trivially pass "LDSP". The missing piece is a whitelist of List-Id:s to trust. If each mailbox has a custom whitelist covering only lists the user subscribed to, there is a significant security-by-obscurity effect that means one is likely to "get away" with trusting a list that is forgeable. "LDSP" would make things more reliable, but would never be the essential component. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "third party signing" != "mailing list problem"
On Mon, 20 Sep 2010, Douglas Otis wrote: > Domains heavily phished are in a different situation. For these And nothing stops them from using full TPA, if they are willing to pay the price. But for most other domains, it's either except-mlist or unknown. > Disagree. A message not signed by DKIM therefore depends upon other > authentication methods. Within a single transaction, the TPA-Label > scheme indicates whether an authentication method should be attempted > for a domain, and whether the domain should be rejected outright without > authentication attempted. TPA doesn't create authentication methods -- it documents whatever the list already has. If a list does not sign, and does not have a predictable and SPF-protected MAIL FROM:, TPA cannot help. If the list is "TPA-able", and the receiver site knows enough about it to construct the TPA records, they can do just as strong verification. > Sorry, but I am unable to follow this. Are you suggesting receiving > domains should compile a white-list for all mailing-lists? Only in the same way that TPA constitutes the sender compiling a white-list. > How will fake SPF record be helpful? I'm referring to the technique of, faced with an entity one wishes to whitelist with no SPF record, constructing a best guess (based on past behavior) as to what its correct SPF record would have been. Then pointing one's SPF validator at the fake record so long as the official result remains "none". Unacceptable false positive risk in my view, but it's hard for a forger to beat. > > You seem to be hinting a global whitelist of mailing lists would be > > feasable -- so the domains in question could just salute one and be > > done with it. > > If they are happy with the results, why not? If they don't cover every list their clients use, recipients will disable incoming DKIM filtering to avoid false positives. Everyone loses. > Are ISPs normally phishing targets? They aren't, but that doesn't mean I want to see messages forged to be from their users. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "third party signing" != "mailing list problem"
On Mon, 20 Sep 2010, Douglas Otis wrote: > It seems this is making two assumptions that are likely incorrect: > > 1) receiving domains know which mailing-lists their users have subscribed. Most don't. But such sites are also incapable of deploying TPA as a sender. So that's just as good an argument for the impracticality of TPA, as for the impracticality of except-mlist. > 2) receiving domains reliably recognize mailing-list messages. This also hurts TPA just as much. The only defense against forgery of lists that can only be recognized weakly (by accepting unsigned messages from any IP that display the correct List-Id:), is not to subscribe to such lists. "except-mlist" comes out slightly ahead here. Since the subscription whitelist is consumed where it is compiled, and thus doesn't need to be converted into a standard "language" such as TPA, it can include ad-hoc measures such as "fake SPF records" to limit forgery of troublesome lists. > > And remember, many big sites will never compile the information needed to > > display a complete TPA policy. Without accomodation (ie: except-mlist), > > "dkim=unknown" is all they can safely publish. > Disagree. While there are many domains offering third-party email > services, this still represents a finite dataset. In contrast, the > domains used by bad actors represent an infinite dataset. You seem to be hinting a global whitelist of mailing lists would be feasable -- so the domains in question could just salute one and be done with it. That doesn't sound practical to me. Especially since users at such ISPs will likely subscribe to lists that are too insecure to be put on the GW. Insecure mailing lists in private whitelist are at least obscure, but a global whitelist cannot tolerate a single one. Basically, the problem is that users at such ISPs do not want protection from forgeries *of themselves directed at others* badly enough to make the sacrifices needed to stop that cold. Such as dropping a non-DKIM, non-SPF mailinglist where all their best friends hang out. But, I want protection from forgeries *of other people directed at me*, and the use of "dkim=unknown" or no-ADSP by those other people hampers my ability to achieve that. I don't need them to go whole-hog TPA, I just need help squelching the supposedly-first-person forgeries, and I can take care of the supposedly-via-list forgeries myself. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "third party signing" != "mailing list problem"
On Sun, 19 Sep 2010, Douglas Otis wrote: > One should not authorize any service that redistributes messages without > first verifying recipient subscriptions. [...] > Spammers would "subscribe" their victims to a mailing-list, and then > submit their messages and have it redistributed by the mailing-list. But if the recipient site happens to have the information it would need anyway to publish TPA on it's own, they can filter out such attempts easily. While they would be agnostic as to whether the putative sender really subscribed to the list, they would know that the *recipient* isn't subscribed and thus the message is bogus. And they can do such filtering even if the putative sender publishes no ADSP at all. However, if ADSP is absent or "dkim=unknown", this protection isn't worth much, since forgeries that make no pretension to be list traffic must be presumed innocent. And remember, many big sites will never compile the information needed to display a complete TPA policy. Without accomodation (ie: except-mlist), "dkim=unknown" is all they can safely publish. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] "third party signing" != "mailing list problem"
On Fri, 17 Sep 2010, Douglas Otis wrote: > Review the TPA-Label draft. The Third-Party Authorization specifies True, TPA does have support for identifying a DKIM-ignorant list based on MAIL FROM: (Although I don't see any support for sites that sign all first-person-mail but are ignorant of user subscriptions.) But, the problem I'm focusing on is that TPA is so much more complicated than plain ADSP. If a protocol was designed to just cover the mailing list problem, it could likely be simpler. The third-party signing use cases that do not overlap the mailing list problem do not seem to be needed badly enough to justify the complexity, IMO. You could say 3PS in SSP tried to piggyback those costly yet less-important cases on top of the mailing-list support, but the extra weight caused the effort to collapse entirely. Thus resulting in the dead-simple yet hostile-to-lists ADSP. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] "third party signing" != "mailing list problem"
Boy, this list has been noisy of late. I've been too overwhelmed to pay attention to every message, but from what I can see, it's a resurgence of the argument between those who wanted ADSP/SSP to be simple and those who wanted "third-party signing" support. (Plus a third faction that just wants things to calm down.) Now, at present, ADSP is near useless, because of the mailing-list problem. (And this is compounded by the ambiguity over what "all" really means.) The 3PS folks are citing this as a sign that the simple-policy folks, who won before, were wrong. But hold on a minute: The "third party signing" problem and the mailing list problem are *not the same*. The latter is a narrower use case. It's not even a subset of literal "third party signing", since any complete solution must accomodate third parties who *do not sign* --- mailing lists that are completely DKIM-ignorant. (Yes, I know any accomodation of legacy lists makes it much much easier to pull off a successful forgery. But as the alternative is "dkim=unknown", it's no loss. An intermediate signal, meaning that mailing lists are the only way the signature can break, would be very helpful to recipients who know what they are subscribed to.) Sure, you can try to force all mailing lists to go through some signing ritual. But if the mailing lists were that willing to bend to accomodate DKIM, they could already accomodate the published RFCs by rewriting the From: on the messages they forward. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"
On Fri, 25 Jun 2010, Dave Crocker wrote: > On 10/16/2009 3:33 PM, Michael Deutschmann wrote: > > I'd like to more emphatically state the case for adding a > > "dkim=except-mlist" policy to ADSP. It will soon become a practical > > issue for me, since my mailserver software (Exim) is going to support > > DKIM in its next version. > > > Simple question: why? That's quite an old message you are responding to. I do not expect any selfish benefit to publishing DKIM/ADSP, even were the mailing list problem completely solved. Someone mentally lazy enough to be tricked in the absence of DKIM would probably be fooled by a sender using the expected full name in combination with an e-mail address he controls. But I'm not entirely selfish -- I would consider publishing merely to help my fellow hacker with his spam control. The point is not to protect him from being *tricked*, but to help him filter out noise at his computer before it reaches his brain. For this purpose a low FP rate is essential. Because of the confusion over what "all" and "discardable" actually mean, when choosing an assertion I must consider the worst case for FPs -- that the recipient thinks both mean "everything unsigned is *definitely* a forgery and thus noise." In turn, the only policy I can publish is "unknown", which provides no help. In order to publish a stronger policy, I would need to abstain from mailing lists and Usenet (because some newsgroups are gatewayed to mail). Sorry, but my charity doesn't extend that far. But I could publish "except-mlist" right now. And it happens that should another site publish "except-mlist", that would be as helpful to my spam defense as if they published "discardable". I could reject incoming messages with missing/broken signatures when the assertion is correctly except-mlist, and be guaranteed no *additional* false positives. The only way this test could false-trigger is if I forget to whitelist a mailing list, and if that happened every message from the list would already be doomed by my anti-Bcc: filter. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On Sat, 22 May 2010, Dave Crocker wrote: > If there is a desire and need to have the semantic be "came from the > mailing list" then there needs to be a mailing list equivalent to ADSP, > which correlates a DKIM signature with the domain in a List-ID header > field. That's not necessary. The weakness of the "except-mlist" approach is not the difficulty of authenticating that a given mail really is from the list it purports to be from. We have off-the-shelf technology to do that: the list manager just needs to use a constant MAIL FROM: domain, and protect that domain with SPF. It requires some cooperation from the list owner, but so would "LDSP". Only if you have irrational Not Invented Here sentiments towards SPF does LDSP become needed. The SPF approach has the advantage that some lists are already in compliance, by accident. Rather, the weakness of "except-mlist" is that it requires that the MX know which mailing lists each mailbox is legitimately subscribed to. Without that, the badguys can pretend the victim subscribes to lists they control. Now, people keep arguing that "except-mlist" is pointless because no regular ISP is so well informed about its own users. But vanity domains like mine *do have the needed intelligence*. The only further knowledge they need, is which sites are publishing "unknown" because they don't sign everything yet, and which sites are publishing "unknown" solely because of the mailing list problem. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On Wed, 19 May 2010, MH Michael Hammer wrote: > +1. The current discussion was supposed to be about BCP. I agree with > Stephen with the caveat that if the group thinks re-opening ADSP > discussion is important then include it in the re-charter. Personally > I'd like to wait until we hear some numbers about ADSP deployment and > experience. Well, if RFC 5617 (current official ADSP) is to be regarded as engraved in stone, writing a list BCP seems trivial to me: There's just two options: 1. Must take ownership of the header From: -- change it to something in the list operator's domain. 2. Should DKIM-sign the outgoing message. 3. Should only accept mails that pass DKIM/ADSP validation, treating "all" as what I call "rejectable". (List input mailboxes don't need to worry about whether "all" means "rejectable" or "except-mlist", because lists don't subscribe to lists). Or: 1. Must relay message verbatim. No subject tags, disclaimers, or "how to unsubscribe" footers. But new headers above the DKIM signature can be ok. 2. Must only accept mails that pass DKIM/ADSP validation, again treating "all" as my "rejectable". After selecting an alternative, breaking any of its musts will risk mails getting blocked, so long as anyone publishes dkim=all (regardless of what they *mean*), and anyone interprets dkim=all as my "rejectable". Neither sounds that palatable to list operators. Which one is mipassoc.org going to use? Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 19 May 2010, John Levine wrote: > If you already know what lists you're subscribed to, why would you do > anything other than accept all the mail from the lists? True, vanity domains likely won't bother to treat "rejectable" differently than "except-mlist". The only difference is in a case that shouldn't happen. But the advantage of "except-mlist" to vanity domains is that *many* more senders are eligible to publish it. They would otherwise use "unknown". With the status quo, vanity domains can only protect themselves from forgeries of: 1. The minority of senders who truly send to no mailing lists 2. Senders who recklessly assume that "all" is universally treated as "except-mlist" Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On Tue, 18 May 2010, Douglas Otis wrote: > Why would you see "rejectable" as being different from "all" assertions? Just about everyone thinks EITHER that "rejectable" would be redundant with "all", OR that "except-mlist" would be redundant with "all". But narrowing "all"'s meaning down to two choices is not an agreement. This ambiguity is paralysing deployment - a conservative sender who means "except-mlist" must publish "unknown", and a conservative receiver who sees "all" must read it as "except-mlist" (and thus as "unknown" in most cases due to ignorance of local users' subscriptions.). Rather than try to settle the fight over what "all" means, let's just deprecate it and give each camp their own, *unambiguous* flag. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 18 May 2010, John Levine wrote: > >If I were in charge, I'd retire "all", to be replaced with two new > >options with clearer semantics. One would be the "except-mlist" I > >proposed a few months back. > > I don't understand what verifiers are supposed to do with that. How > is an MTA doing the DKIM verification and filtering supposed know > what's a mailing list and what's not? If I were a bad guy, I'd put > fake headers on my spam to make it look like a list mail. 1. "except-mlist" is primarily for the benefit of vanity domain recipients who have programmed their MTA with knowledge of exactly which lists they are subscribed to. Just guessing which list to forge is a big hurdle for the bad guys. *I* recognize friendly mailing lists by their MAIL FROM: domains, which means SPF will also be an obstacle to such forgers. But yes, big ISPs that know no details about their users have to treat "except-mlist" as "unknown". But they still gain, because they will know everyone who publishes "rejectable" really means it. 2. As I touched on in a parenthetical at the end of the message, mail heading to a mailing list *input* can be processed as if "except-mlist" was "rejectable". Lists don't subscribe to other lists. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On 18 May 2010, John Levine wrote: > Agreed. We have no idea what "all" means in practice, other than perhaps > an ill-defined small decrement to some sort of reputation if the signature > isn't present. If I were in charge, I'd retire "all", to be replaced with two new options with clearer semantics. One would be the "except-mlist" I proposed a few months back. The other would be "rejectable". "rejectable" would indicate that all missing/bogus signature mail is to be rejected -- the reciever is not to worry about the possibility that the message went through a mailing list. "rejectable" would differ from "discardable" only in the case of a validator that has no ability to reject in-transaction. The most obvious case would be a DKIM-checking plugin for an MUA using POP3 with a DKIM-unaware ISP. "discardable" would tell the MUA that it is ok to simply drop invalid messages. "rejectable" would indicate that, should it be impossible to send the problem message backwards, it is better to let it go forward to the end user than to blackhole it. "discardable" would be the choice for those paranoid about phishing in their name. "rejectable" would be for those who are eligible to use "discardable", but prefer not to risk mail *silently* disappearing should a bug cause the signature to appear bad to some receivers. Sending a bounce message would comply with the spirit of rejectable, but that is not wise in general as the internet is beginning to punish backscatter. Unless the problem message's MAIL FROM: is independently proved valid (eg: by SPF), discarding or delivery are the only choices a late-acting validator has. (One note referencing things upthread: Back when I proposed "except-mlist", most objections were on the basis that there is no *automatic* way for the reciever to implement it differently from "unknown"; only vanity-domain recipients can benefit. But it would be correct for a mailing list input mailserver to treat "except-mlist" as "rejectable", since lists don't mail to each other.) Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Refocusing on the re-charter
On Sun, 18 Oct 2009, Barry wrote: > My point, Michael, is that it doesn't matter what we "decide" in the > working group. As John pointed out, what's relevant is not that he I'd disagree. All we need is an explicit statement in an RFC as to which policy is "correct" in the common case that the sender is very confident that all non-mailing-list mail will have an unbroken signature, but cannot make any promises otherwise. Once it is explicit, we won't have to worry about private interpretations. If you really want to close this, I can't stop you. I just think publishing an "except-mlist" policy to cover this common case, or at least clarifying which of the existing policies to use, would have been low-hanging fruit allowing us to improve the quality and quantity of ADSP deployment. But for now, once Exim 4.70 is released, giving me the ability to actually participate in DKIM, I shall be publishing a dkim=unknown record. (If you build "except-mlist", I will come...) Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Refocusing on the re-charter
On Sun, 18 Oct 2009, Barry wrote: > Now we're talking about the "Thomas > interpretation" and the "Levine interpretation", and I posit that it > doesn't matter, at this point, whether they have different > interpretations (actually, I like John's most recent post on that), > and we won't know who's "right" until we have time to get more data. It is of some actual importance to resolve this schism. If receivers are afraid senders will follow the Thomas interpretation, and say "dkim=all" despite posting to mailing lists that break their signatures, they will not act on "dkim=all". If senders are afraid receivers will follow the Levine interpretation, rejecting broken signatures at CR LF '.' CR LF without first whitelisting mailing list traffic, they will not post "dkim=all". Result: ADSP doesn't block a thing. > and to avoid pugilism. Or perhaps you can get Dave to start up a new I haven't noticed any incivility in these discussions. And while I lean towards Levine, it doesn't really matter to me which side wins. Indeed, a decisive Thomas victory would remove the need for except-mlist. It's only the ambiguity that is a problem. (So as someone in authority, if you *choose one side* and close the book, it just might stay closed...) Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"
On Sat, 17 Oct 2009, hector wrote: > I don't quite understand your suggestion. Who is creating this > DKIM=except-mail ADSP++ record? The Author Domain or the Mailing list > Server? The header From: domain, as always. > Who owns, creates, maintains, updates this Global White List you speak > of? Now, this is why dkim=except-mlist-on-global-whitelist is not low-hanging fruit like dkim=except-mlist. But the Global Whitelist was not intended as a practical suggestion so much as a rhetorical device in my argument that dkim=except-mlist can't be improved upon, despite the fact that it leaves big ISPs (who don't know what lists their users subscribe to) high and dry. Basically, it seems inescapable to me that reliable forgery detection requires the kind of mailserver knowledge that only vanity domains have. One end of the connection can be a big, ignorant ISP, but either the recipient or sender mailserver must be aware of all mailinglist subscriptions. If neither sender signer nor recipient validator knows which mailinglists the users use, they are vulnerable to spammers who pretend to be mailing lists. Neither SPF nor a hypothetical ADSP-like protocol that covers List-ID: instead of From: can help here, since the controlling DNS records will be on enemy territory. A global whitelist is the obvious answer to that problem. But since the GW can't list forgeable mailing lists (since all a spammer needs is a single forgeable mailing list to spam everyone who trusts the GW), it will in practice never be able to cover all the real mailinglists people actually use. So a sender can only signal (in its ADSP) the validator to apply the GW, if no user subscribes to an untrusted list and the admin *knows this*. Note: If we *accept* the onerous requirements of the GW -- that the sender mailserver has to be informed of all subscriptions, and that some cooperation from the listservers is required, I can see better solutions than the GW. But I still think it best to drop the costs on the receiver side with except-mlist. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Thomas Interpretation vs. Levine Interpretation
On Fri, 16 Oct 2009, Ian Eiloart wrote: > > (Incidentally, anyone have a better name for this policy?) > > "dkim=all" If you read ADSP in conjunction with section 3.1 of RFC 5016, > then "dkim=all" means exactly that: "Domain Alice provides information that > it signs all outgoing mail, but places no expectation on whether it will > arrive with an intact first party signature." You're endorsing the Thomas interpretation, here. I'd just note that the following, from RFC 5617, section B.1: # In this situation, it might be appropriate to publish an ADSP record # for the domain containing "all", depending on whether the users also # send mail through other paths that do not apply an Author Domain # Signature. Such paths could include MTAs at hotels or hotspot # networks used by travelling users, web sites that provide "mail an # article" features, user messages sent through mailing lists, or # third-party mail clients that support multiple user identities. ... seems to endorse the Levine interpretation. "user messages sent through mailing lists" is explicitly listed as a contraindication to an "all" policy. But whatever, we may need a straw poll followed by a clarification RFC, to settle once and for all whether Levine or Thomas is canon. My leaning is that Levine is more faithful to the RFCs as published, but Thomas would be more useful. I favor my "except-mlist" as a third option, allowing us to gain the benefits of Thomas while yielding to Levine. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"
On Fri, 16 Oct 2009, hector wrote: > mich...@talamasca.ocis.net wrote: > > But you don't need to be a vanity domain to *advertise* except-mlist, and > > us vanity domains would appreciate it if you do. > > If you could Package this and provide it as a persistent protocol > methodology for everyone to follow, then GO WEST!! The problem is that any solution that doesn't require the intelligence typically only possessed by vanity domains, will require a global whitelist of mailing lists -- so that spammers and phishers cannot make fake lists just to use the back door. To improve upon except-mlist as I've described it, every mailinglist in the whitelist must be unforgeable -- either via SPF, or a third-party DKIM. No exceptions, since the public whitelist neutralizes the SbO advantage of the vanity-domain approach. Then, we have the problem that a site can only publish "dkim=except-mlist-on-global-whitelist" if it *knows* that none of it's users subscribe to mailinglists unknown or unacceptable to the GW. So, we've then made a lateral move from a policy that can only be *applied* by vanity domains, to one that can only be *advertised* by vanity domains It's still a worthy goal, which is why I've suggested that we also reserve a namespace of policy names which devolve to except-mlist when not specifically known to a validator. It just doesn't replace naked except-mlist. (Actually, I see one escape from the global whitelist -- a sender could program his mailserver to recognize mail outgoing to trusted mailing lists and use l=0 signatures in that case. But that is also practical only for vanity domain senders.) Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Case for ADSP "dkim=except-mlist"
On Fri, 16 Oct 2009, hector wrote: > How does a receiver know that the client is sending list mail? Do they > need to look at some other 2822/5322 header? In many cases, they don't. Then they have to treat dkim=except-mlist as dkim=unknown. But they lose nothing from the existence of dkim=except-mlist. But *I* can treat dkim=except-mlist as dkim=all, because my mailserver is programmed to specifically recognize the six mailing lists I am subscribed to, by their bounce addresses. In theory, a spammer could forge them, since none of them (not even spf-discuss!!) use SPF. But guessing which list to forge is an SbO that the spammers have not pierced yet Impersonating any list other than those 6 is futile -- it will bounce off my anti-Bcc filter. Loosely, you could say that dkim=except-mlist is equivalent to dkim=unknown when the validator is a big ISP, and equivalent to dkim=all when the validator is a vanity domain. But you don't need to be a vanity domain to *advertise* except-mlist, and us vanity domains would appreciate it if you do. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Case for ADSP "dkim=except-mlist"
I'd like to more emphatically state the case for adding a "dkim=except-mlist" policy to ADSP. It will soon become a practical issue for me, since my mailserver software (Exim) is going to support DKIM in its next version. Without it, I'd have to use "dkim=unknown", which is effectively no ADSP at all. To review, "dkim=except-mlist" would mean: I sign everything leaving my bailiwick, but may post to mailing lists that break the signature. You are *on your own* in telling the difference between mailing list mail (which may be good despite a broken signature) and directly sent mail (that is always signed). If you can't tell, then treat as dkim=unknown (ie: assume a message is ML traffic unless you know otherwise.). (Incidentally, anyone have a better name for this policy?) -- The determination of whether it is good to add a new policy to ADSP should rest on three issues: 1. Is it backwards compatible? 2. Will senders ever deploy it? 3. Will receivers ever treat it differently than what the senders would use if it were unavailable? For #1, it is indeed compatible. RFC 5617 explictly says that unknown values are to be treated identically to "unknown". Under Levine's interpretation of RFC 5617, "unknown" is clearly the best approximation to "except-mlist". Under the Thomas interpetation, it is a small step back, but enough people endorse the Levine interpretation that it would be foolish to count on sites treating "all" as "except-mlist". For #2, do I even need to argue? Any site that passes all outgoing mail through a DKIM-aware smarthost qualifies for "except-mlist", but not for "all" if there are any mailing list subscribers. #3 is the weakest point, but I can offer my personal testimony that I have all my mailing lists whitelisted, and could thus only improve my bad-mail determination accuracy if this extra information was available in the ADSP records of purported senders. (By the way, it might be a good idea to pre-reserve a family of policy names, which would have the property of devolving to "except-mlist" instead of "unknown" when the validator does not know them specifically. This would allow 100% backwards-compatible later deployment of schemes that provide for easier detection of desired mailing list traffic.) Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)
On Mon, 12 Oct 2009, Ian Eiloart wrote: > It also seems to me that there must be a difference between "dkim=all" and > "dkim=discard". Publishing "discard" should mean that there's no My understanding is that the all/discard distinction is orthogonal to the mailing list issue. I think the motivation for discard is to give guidance when someone realizes a message seems to be forged after it has already been accepted by their MX. This could happen, say, if a user at a DKIM-unaware ISP installed a DKIM-analysing plugin into their MUA. In this situation, there are only three choices: 1. Send a bounce message 2. Drop it silently 3. Ignore the validation failure and show it to the user anyway. #1 is clearly unacceptable in this day and age, since in the frequent case that the message was indeed forged, the bounce would be backscatter. (Unless perhaps SPF asserted the provenance of the bounce address.) dkim=discard hints that people in this situation should take option #2. It would be appropriate for sites that really, really, don't want their users to ever see a phish. dkim=all hints that people in this situation should take option #3. It makes mail less likely to be mysteriously lost if there is a screwup in the signing of the legitimate mailstream. Ideally, of course, all improperly signed mail would be rejected at CR LF '.' CR LF, and this distinction would be irrelevant. discard, all, and except_mlist thus cover three corners of a square. In theory we could have a fourth option, that provides for silent discard of mail that fails DKIM and is clearly not legitimate mailing list traffic. But I don't think anyone would ever use it. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)
On Mon, 12 Oct 2009, Wietse Venema wrote: > Michael Deutschmann: > > If this is indeed the official semantics of the protocol, then I would > > petition to add a "dkim=except-mlist" policy. Which means "I sign > > everything that leaves my bailiwick, but may post to signature-breaking > > MLs." > > Are you going to announce all your users mailing list subscriptions > in the policy record? If you do, that could be a privacy problem. > > If you don't, then the spammer can add any mailing list header to > the message, and they can drive their truck through this hole. The only other option for a sender domain with any subscribers to signature-breaking mailing lists, is dkim=unknown. Which is just as big a hole. At least with dkim=except-mlist, the recipient can narrow the loophole to cover only those mailing lists he is actually subscribed to. If those mailing lists use SPF, the spammer can't get in even if he knows which ones to forge. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)
On Mon, 12 Oct 2009, hector wrote: > The key point that is being missed here is that doesn't matter if we > all agree to add 3rd party or mailing list support to an extended RFC > 5617 policy protocol. If resigners are going to be exempt from any > mandate to support it, it will remain to be conflict with receivers. I don't like the term "resigners" here. Many mailing lists will do no signing at all. For whitelisting purposes, they may instead rely on SPF, or just the hope that spammers won't guess the List-Id: or envelope sender domains of the lists their victims subscribe to. Compared to the more elaborate schemes bandied here, dkim=except-mlist's strength and weakness is the same thing -- it leaves the question of *how* to recognize legitimate mailing list traffic in the recipient's hands. Those of us with vanity domains have hands quite capable of handling that problem without recourse to some hypothetical third-party-signatures standard (which will likely flop among ML admins just as SPF's SRS flopped among forwarders...). "dkim=except-mlist" is all *we* need. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)
On Sun, 11 Oct 2009, Dave CROCKER wrote: > Michael Deutschmann wrote: > > While I don't think the Hector/Levine interpretation is very useful, I > > think it would be a sound strategic move to yield to them regarding > > dkim=all, and instead create our own dkim=except-mlist space where our > > semantics are in place with *no ambiguity*. > > Whatever the semantics that you have in mind, the underlying question is who > will adopt it and what is your basis for claiming they will adopt it? The > next > question is whether the answers to the first question justify the considerable > costs of pursuing this suggestion. At the sender side, dkim=except-mlist would be very attractive if the Levine interpretation of dkim=all stands. No large ISP could deploy the Levine all. But as a practical matter, any organization with DKIM-supporting smarthosts, that already uses SPF's "-all", could deploy dkim=except-mlist at minimal risk. At the receiver side, it's a little less useful, since no means is given to tell whether a message is exempt mailing list traffic or must-be-signed normal mail. Hence big ISPs are forced to accept some false negative risk by treating except-mlist as unknown. However, for people like myself who have whilelisted all incoming mailing lists, except-mlist would be so much more helpful than unknown. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)
On Sun, 11 Oct 2009, Michael Thomas wrote: > On 10/11/2009 02:41 AM, Michael Deutschmann wrote: > > If this is indeed the official semantics of the protocol, then I would > > petition to add a "dkim=except-mlist" policy. Which means "I sign > > everything that leaves my bailiwick, but may post to signature-breaking > > MLs." > > No need. That is exactly what the semantics of "all" is. That appears to be a contentious issue. While I don't think the Hector/Levine interpretation is very useful, I think it would be a sound strategic move to yield to them regarding dkim=all, and instead create our own dkim=except-mlist space where our semantics are in place with *no ambiguity*. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)
On 10 Oct 2009, John Levine wrote: > People who contribute to mailing lists shouldn't say dkim=all. We > argued this ad nauseam when we were hammering out ADSP, it shouldn't > come as a surprise to anyone. I'm an outsider delurking to say: If this is indeed the official semantics of the protocol, then I would petition to add a "dkim=except-mlist" policy. Which means "I sign everything that leaves my bailiwick, but may post to signature-breaking MLs." I would find the distinction between this and "unknown" to be useful information when evaluating incoming mail. I whitelist all mailing list traffic -- I have to, because I've programmed my mailserver to reject Bcc traffic otherwise. *I* would be able to treat except-mlist as all. But for an ISP that doesn't know its users well, except-mlist = unknown. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
