Re: [ietf-dkim] Why mailing lists should strip DKIM signatures
I've read through all the responses on the list but I'm responding to John's original message because so much of the responses have made critical assumptions about the nature of the FBL with Yahoo!. John, can you simply clarify the rules/logic of your FBL with Yahoo!? That will clarify this scenario considerably. Brett McDowell Technology Evangelist, Information Risk Management, PayPal On Apr 23, 2010, at 12:34 AM, John Levine wrote: > For anyone who's working on the list management BCP: > > I sign all my outgoing mail, and I have a feedback loop set up with > Yahoo, which being very modern and advanced keys on signatures, not IP > addresses. A few days ago I sent some messages to one of the Freebsd > mailing lists. Today some Yahoo user who subscribes to that list hit > the spam button. Freebsd's list software (Mailman, I think) doesn't > sign, and doesn't strip any headers. So what happened? Yahoo saw my > signature and sent the reports to me, which was of course useless > since I don't run the list. > > This is not a hypothetical problem--all of my recent Yahoo FBL reports > have been for mail I sent to mailing lists elsewhere. The lists I do > run sign their mail, and FBL reports for those lists are handled > reasonably. My scripts do what they can with this stuff, but sending > unsub commands to majord...@freebsd.org doesn't work. > > R's, > John > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
On Apr 26, 2010, at 10:05 AM, MH Michael Hammer (5304) wrote: > I think we are having the wrong discussion. The real question is: > > "What are appropriate practices for mailing lists in handling DKIM > signed mail?" Agreed. >From my perspective, I'd like to enable (not mandate or expect universal >compliance with) the deployment scenario where the sender's DKIM signature is >either maintained without adulteration or "proxied" by the list so the >transient trust can be carried through the mailing list intermediary to the >destination (per Murray's note which I'm also going to respond to). That's my >use case. By sharing this use case I'm not trying to deprecate or undermine >John Levine's original use case. But there is a diversity of >valid/appropriate behavior by mailing lists vis-a-vis DKIM that we need to >consider (which is why I'm so pleased to see Mike H. take our discussion in >this direction). -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
On Apr 23, 2010, at 12:56 PM, John Levine wrote: >> John, can you simply clarify the rules/logic of your FBL with Yahoo!? >> That will clarify this scenario considerably. > > It's just like the IP based FBLs that other mail systems have, only > keyed on DK or DKIM d= signing domains rather than IP addresses. I > tell them what my d= domains are, they send reports when recipients > complain. I expect Paypal has the same arrangement with them. If you > don't, you should. First off, thank you for clarifying this John. As for PayPal, we have a different relationship with Yahoo! that better addresses our needs: https://www.thepaypalblog.com/2007/10/yahoo-paypal-an/ Our motivation is consumer protection. > > The terms of service are pretty typical, I can't redistribute the FBL > reports since they're unredacted, and I can use them for " (a) > reducing the incidences of your legitimate email being filtered by > Yahoo!'s spam filtering system or being marked as "spam" by Yahoo! > Mail users and (b) enforcing your spam policies." > > You can see the TOS here: > > http://feedbackloop.yahoo.net/tos.php > Granted, this is a nice service for monitoring recipient behavior vis-a-vis the spam button, thus helping you enforce your spam policies. I'm sure we do something similar, but that's not my department nor where I think DKIM really flexes it's muscle. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
On Apr 23, 2010, at 6:28 PM, Murray S. Kucherawy wrote: > Something like: X sends to a list at Y that then relays to Z; Z trusts Y to > implement DKIM and Authentication-Results and all that properly, so Z > believes Y when it says "X had a signature on here that verified" even if X's > signature on arrival at Z is either invalid or absent. That's interesting. Let's make this concrete... I'll use myself as an example. X = me/PayPal.com Y = this list/ietf-dkim@mipassoc.org Z = Google's Gmail service [1] It is my assumption that someone subscribed to this list has a gmail.com account (or a Yahoo.com account [2]). Therefore, my use case is simple. I would hope that those of you reading this from your Gmail or Yahoo! accounts actually receive this message. If Z breaks the signature, you won't see this. So if it simply isn't practical to expect lists to maintain the signature, then offering the option for the list to validate the signature coming from X and send a new signature to Z that Z *can* (but doesn't have to) "trust", is something immediately useful. Murray, is this what you discussed supporting in IETF #77? If yes, what's the status? -- Brett [1] https://www.thepaypalblog.com/2008/07/google-joins-th/ [2] https://www.thepaypalblog.com/2007/10/yahoo-paypal-an/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
On Apr 27, 2010, at 1:34 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: Jeff Macdonald [mailto:macfisher...@gmail.com] >> Sent: Tuesday, April 27, 2010 10:05 AM >> To: McDowell, Brett >> Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists >> should strip DKIM signatures >> >>> That's interesting. Let's make this concrete... I'll use myself as >> an example. >>> >>> X = me/PayPal.com >>> Y = this list/ietf-dkim@mipassoc.org >>> Z = Google's Gmail service [1] >>> >>> It is my assumption that someone subscribed to this list has a >> gmail.com account (or a Yahoo.com account [2]). Therefore, my use case >> is simple. I would hope that those of you reading this from your Gmail >> or Yahoo! accounts actually receive this message. If Z breaks the >> signature, you won't see this. >> >> how about Y breaking the signature? I see your message only because I >> told gmail's filtering system to not put messages into the spam folder >> for this list. Otherwise it would of gone into the spam folder. >> Looking at the source of the message, I only see the list's DKIM >> signature. > > Y breaking the signature isn't relevant (in this hypothesis). Y also says > when it got the message from X, X's signature was intact. That Y messed up > the signature, making Z unable to verify it directly, is not important; Z > trusts Y, so Z trusts Y's Authentication-Results: that says X's signature was > fine when it got to Y. > >> Should the policy statements be ignored at that point? > > In this hypothesis, they could be. Or, they could be applied. If X's ADSP > says "all" or "discardable", and Z trusts Y, and Y claims X's message had a > valid signature, ADSP is satisfied. > That's how I see it. The key is that Y *validates* the DKIM signature and processes the sender's ADSP when it receives the message before taking it's next action. If Y didn't actually validate with comparable rigor as Z, then Z would have no basis to trust mail from Y. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
On Apr 27, 2010, at 1:50 PM, Dave CROCKER wrote: > On 4/27/2010 10:40 AM, McDowell, Brett wrote: >> That's how I see it. The key is that Y *validates* the DKIM signature and >> processes the sender's ADSP > > > Where is this going to be supported? That is, how widespread does anyone > believe that support for this scenario will be? Why? I'm not sure if you were asking this as a rhetorical question in an attempt to imply that such adoption would be low, or if you actually expected some of us who may have non-public knowledge of such plans to disclose them to this public mail list, or if you were soliciting speculation. In any event, I can only speculate. But since both Yahoo! and Google already validate DKIM and (with certain senders anyway) enforce "discardable", it's no great stretch of the imagination that they might support something like what we've articulated above for their Google Groups/Yahoo! Groups services. Why might they do it? For all the same reasons they do DKIM blocking today... whatever those reasons may be. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
Who do you feel we need to hear from at this stage to gauge interest? -- Brett On Apr 27, 2010, at 2:32 PM, Dave CROCKER wrote: > > > On 4/27/2010 11:08 AM, McDowell, Brett wrote: >> On Apr 27, 2010, at 1:50 PM, Dave CROCKER wrote: >>> On 4/27/2010 10:40 AM, McDowell, Brett wrote: >>>> That's how I see it. The key is that Y *validates* the DKIM signature >>>> and processes the sender's ADSP >>> >>> Where is this going to be supported? That is, how widespread does anyone >>> believe that support for this scenario will be? Why? >> >> I'm not sure if you were asking this as a rhetorical question in an attempt >> to imply that such adoption would be low, or if you actually expected some of >> us who may have non-public knowledge of such plans to disclose them to this >> public mail list, or if you were soliciting speculation. In any event, I can >> only speculate. > > > I meant the question quite seriously. > > When trying to specify anything, it's important to be clear about who is the > target for adopting it and how motivated they will be and how feasible > adoption > will be within a useful timeframe. > > If the specification is only intended for Yahoo and Google and there are good > signs they will adopt it, then fine. > > If the goal is broader adoption, then Yahoo and Google can actually be > misleading examples, since they are not representative of the wider mailing > list > management software or operations community. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
On Apr 27, 2010, at 2:57 PM, Dave CROCKER wrote: > > On 4/27/2010 11:48 AM, McDowell, Brett wrote: >> Who do you feel we need to hear from at this stage to gauge interest? > > > For any specification, it helps to hear from the folks who will write the > software and from the folks who will deploy and use it. But I interpreted your earlier comment as indicating that Google and Yahoo were irrelevant and/or non-representative for the sake of this exercise. But they write code and deploy mail systems that touch hundreds of millions of people. So I'm trying to understand who you would consider relevant and representative for the sake of gauging interest in this use case. I'd be happy to talk to them about it, once I know who they are. > > "If we specify it, they will come" is a very risky approach to standards > making. > c.f, <http://trac.tools.ietf.org/misc/outcomes/>. > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Random suggestion
Since you brought it up... ;-) I would say there is no single "primary benefit" to DKIM. I would say there are "many benefits" to DKIM. And, to be explicit about it, I believe applying DKIM for the purpose of "consumer protection" is at least as valid a benefit of DKIM as applying it for "improved deliverability". -- Brett On Apr 27, 2010, at 12:18 AM, Dave CROCKER wrote: > As folks talk about using DKIM for any near-term, primary benefit, try > starting > with the premise that it is for aiding in deciding what mail to accept, > rather > than for finding a way to throw mail away. > > It significantly changes the discussion. > > d/ > > ps. Hint: ogic of the form "knowing what to throw away helps in deciding > what > to accept" is counterproductive to this exercise. > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
So Murray... you mentioned you started talking to folks about this use case at IETF 77. Were any of them MLM vendors or service providers? Are there MLM vendors or service providers on this list who feel they know enough about this use case at this point to have a firm position either for or against standardizing this functionality? Speaking for myself (as neither a MLM vendor or service provider), I found Murray's use case interesting and could see how such functionality might plug a current hole in the DKIM fabric. I also see immediate applicability for our PayPal customers. But I don't know enough about the use case or the potential solution to make a firm commitment one way or the other right now. All I'm saying is that it seems worth exploring further. Dave seems to be seeking confirmation of interest from MLM vendors and service providers at this early stage in order to continue to develop the concepts. So... is there any other interest in this scenario... form MLM vendors or service providers? -- Brett On Apr 27, 2010, at 3:11 PM, Dave CROCKER wrote: > > > On 4/27/2010 12:04 PM, McDowell, Brett wrote: >> On Apr 27, 2010, at 2:57 PM, Dave CROCKER wrote: >>> For any specification, it helps to hear from the folks who will write the >>> software and from the folks who will deploy and use it. >> >> But I interpreted your earlier comment as indicating that Google and Yahoo >> were irrelevant and/or non-representative for the sake of this exercise. > > I think the confusion is the difference between hearing individual examples, > versus extrapolating them to the larger community. Yahoo and Google are > important and useful. But they are not representative. > > >> So I'm trying to understand who you would consider relevant and >> representative for the sake of gauging interest in this use case. > > There is a large world of people who develop MLM software and a much larger > world of people who operate MLM services. If we are specifying rules for > them, > it would help to hear from them, that they are interested in implementing > what > we direct them to implement. > > Since I haven't been the one espousing change for MLMs, I'm hesitant to be > the > one to try to specify who folks want to have implement this. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Apr 28, 2010, at 2:11 PM, John R. Levine wrote: >> >> Your proposal that MLM remove Signatures would cause restrictive >> policies to fail. Which is why I oppose this proposal. > Indeed. I'm assuming that any list that paid attention to ADSP would sign > its outgoing mail and would expect its recipients to trust it enough to > whitelist the list's mail. That's quite an assumption. I would not make that same assumption as we chart out new/better mechanisms for MLM's to handle DKIM-signed mail. It will be true in some cases, and false in others. All for valid reasons we should seek to account for. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
Gentlemen... There has *not* been a report of any misconfiguration on paypal.com. The report, which I've taken off-list and am actively chasing down, actually *may* indicate that gmail is not consistently blocking broken DKIM signatures from paypal.com (which our ADSP asks and they have voluntarily chosen to honor/implement), but that has not been substantiated yet and I actually don't expect it will be once all the facts are in. But again, that's an off-list issue. There *is* an on-list issue that John raised and I will respond to his message next. -- Brett On Apr 29, 2010, at 2:12 PM, Michael Thomas wrote: > On 04/29/2010 10:42 AM, Powers, Jot wrote: >> On 4/29/10 10:34 AM, "Michael Thomas" scribbled: >>> On 04/29/2010 10:23 AM, Al Iverson wrote: As John Levine mentioned previously, your own posts to this list fail authentication and end up in many of our spam folders because of Paypal's SPF policy. I'm not against strong authentication policies -- but I'm wondering how you personally expect to be able to post to mailing lists without acceptance of this proposal? The status quo interferes with your ability currently, and broader adoption of authentication on the receiving side will only make it worse. >>> >>> The solution to a misconfigured SPF/ADSP record is for every receiver to >>> patch it up post-hoc? That makes absolutely no sense. >> >> I must have missed it. What exactly does PayPal have misconfigured? >> >> Off-list is fine. > > I'm not sure that paypal.com actually has anything wrong -- i'm not > a spf expert, but it seems that you're set to ~all which isn't a very > restrictive policy iirc. I'm only responding to Al's assertion that your > SPF record is causing mail to be filtered as spam. If I had to guess, > I'd say it's the spam filter's problem, not yours. > > With respect to DKIM, anybody who filters based on broken signatures without > any (or little) other input pretty much deserves the false positive rate > they're > complaining about. > > Mike > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
(oops, sorry, it was an issue Al raised, not John... in any event here's my answer) On Apr 29, 2010, at 1:23 PM, Al Iverson wrote: > On Thu, Apr 29, 2010 at 11:58 AM, McDowell, Brett > wrote: >> On Apr 28, 2010, at 2:11 PM, John R. Levine wrote: >> >>>> >>>> Your proposal that MLM remove Signatures would cause restrictive >>>> policies to fail. >> >> Which is why I oppose this proposal. > > As John Levine mentioned previously, your own posts to this list fail > authentication and end up in many of our spam folders because of > Paypal's SPF policy. I'm not against strong authentication policies -- > but I'm wondering how you personally expect to be able to post to > mailing lists without acceptance of this proposal? The status quo > interferes with your ability currently, and broader adoption of > authentication on the receiving side will only make it worse. It's a question of priority and timing. Priority: it's more important to us that cyber criminals not be systemically enabled to leverage MLM systems to bypass email authentication flows and consumer protection policies designed to block their attacks... the attacks that, if not for the MLM intermediary, would have been blocked thanks to DKIM+ADSP and the voluntary compliance to ADSP policies by certain ISP's/Mailbox Providers. Timing: therefore, until the standards community enables MLM systems to maintain (if they wish) the integrity of DKIM/ADSP-enabled message authentication flows that exist today (and are on the rise) and would successfully deliver authenticated mail if not for the intervention of the MLM system, our consumer protection policy has this apparent consequence on PayPal employees that participate in certain public mail lists -- the ones that break or strip DKIM signatures -- that would lead us to have to perform workarounds as the issues are discovered. It's not ideal for me personally, but more importantly it's not ideal for any sender trying to leverage these technologies to improve consumer protection. That's why I'm here trying to advocate for a *solution* which Murray's proposal just might be the basis for, but I humbly assert John's is not. I'd characterize the X-Y-Z proposal from Murray as having some hope of solving the problem without dismissing the current consumer protection values of DKIM+ADSP, and John's proposal as something akin to giving up on ever seeing authenticated mail survive MLM intermediaries. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Apr 29, 2010, at 3:47 PM, Graham Murray wrote: > "McDowell, Brett" writes: > >> Priority: it's more important to us that cyber criminals not be >> systemically enabled to leverage MLM systems to bypass email >> authentication flows and consumer protection policies designed to >> block their attacks... the attacks that, if not for the MLM >> intermediary, would have been blocked thanks to DKIM+ADSP and the >> voluntary compliance to ADSP policies by certain ISP's/Mailbox >> Providers. > > Though is the fact that a mail arrives via an MLM not also a very strong > contra-indication of the validity of nearly all mail which would > constitute such an attack? Irrespective of any other factors, the mere > fact that it arrives via an MLM is an almost certain indication that any > mail which purports to tell you that you have won a lottery, been given > a bequest, have a problem with your account, need to contact a company > about some purchase or other problem etc, is almost 100% certain to be > either a phishing attack, a forgery or a scam. In almost all cases, > genuine mail sent via an MLM is not of the nature which requires such > authentication or falls within consumer protection polices. That's a very reasonable position to take and it makes good common sense. But I've been surprised by frighteningly common consumer behavior that flies in the face of good common sense. But still, I think you have a point and we'd have to turn to the experts on whether the data shows fraud caused by phishing attacks that were delivered by mail lists. I don't know the answer to that right now. > > To take your postings here as an example. Mail from PayPal about > people's accounts, policy changes etc needs to be protected and pass > authentication. However, whether or not your postings here authenticate > as genuinely coming from PayPal is not really important and in no way > affects the validity of the points you make in your posts. But here is where I must differ. For example, let's say we created a subdomain that we used for all transactional mail and that was the only domain we asserted "discardable" for. Well, we just handed the Phishers all of our other domains and they would be more than happy to use those. The consumer doesn't and really never will consistently discriminate between the mail we tell them to trust vs. the mail we tell them not to trust... it's sad and frustrating, but it's reality. Even if you flipped the use case and asserted ADSP discardable for all domains except one that you use for employees... like maybe corp.paypal.com. Well, you just handed the Phishers corp.paypal.com. We still have the cousin domain problem, as you all know. But we are trying to reduce the threat surface as much as we can. I think a DKIM-for-MLM's spec just might help reduce that threat surface a bit more. BTW, I didn't join this list to become the center of attention :-) Aren't there other heavily-phished senders on this list who can speak to these issues and use cases? -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Apr 29, 2010, at 9:06 PM, John Levine wrote: > I just don't see how you can simultaneously say "throw away unsigned > mail" and "don't throw away unsigned mail if a list says it used to be > signed" unless you have some way to identify trustworthy lists. Precisely! The key phrase being "unless you have some way to identity trustworthy lists" > But > once you know that a list is trustworthy, why wouldn't you just accept > all its mail? We need to be precise about what we mean by "trustworthy". Even if I have "some way to identify trustworthy lists" as you put it above, I have to be very clear about what I'm actually trusting that list to do. Let's go back to the use case I drafted in response to Murray's report that introduced the MLM re-signing option. >> That's interesting. Let's make this concrete... I'll use myself as an >> example. >> >> X = me/PayPal.com >> Y = this list/ietf-dkim@mipassoc.org >> Z = Google's Gmail service [1] >> >> It is my assumption that someone subscribed to this list has a gmail.com >> account (or a Yahoo.com account [2]). Therefore, my use case is simple. I >> would hope that those of you reading this from your Gmail or Yahoo! accounts >> actually receive this message. If Z breaks the signature, you won't see >> this. >> >> So if it simply isn't practical to expect lists to maintain the signature, >> then offering the option for the list to validate the signature coming from >> X and send a new signature to Z that Z *can* (but doesn't have to) "trust", >> is something immediately useful. In that scenario, if the MLM re-signing solution has been deployed by Y, and DKIM+ADSP has been deployed by X & Z, and Z has chosen to take action on X's ADSP policies... the only thing Z is trusting Y to do is validate incoming DKIM signatures, re-sign the messages with its own DKIM signature, and pass it along with the A-R results that convey what was done. Z is not trusting everything and anything that might ever come through Y. I think that's a reasonable level of trust to expect mailbox providers to have in mail lists who assert that they do this. Rogue mail lists will stop being trusted but only after they have "lost" the trust that was granted to them via their standards-based assertion (we would probably need to spec out how a MLM advertises that they indeed conduct flows in this manner) that they perform these functions on incoming mail. Again, I'm not saying this is the best or most elegant way of handling the problem of properly authenticated mail not being able to traverse mail lists, but it seems worthy of further discussion as an option. > I just don't see a plausible scenario where you you > know you trust the list but still want to accept or reject mail based > on assertions the list itself makes. Does the use case I've articulated above make sense? -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Apr 30, 2010, at 5:30 AM, Ian Eiloart wrote: > --On 29 April 2010 10:58:44 -0600 "McDowell, Brett" > wrote: > >> On Apr 28, 2010, at 2:11 PM, John R. Levine wrote: >> >>>> >>>> Your proposal that MLM remove Signatures would cause restrictive >>>> policies to fail. >> >> Which is why I oppose this proposal. >> >> >>> Indeed. I'm assuming that any list that paid attention to ADSP would >>> sign its outgoing mail and would expect its recipients to trust it >>> enough to whitelist the list's mail. >> >> That's quite an assumption. I would not make that same assumption as we >> chart out new/better mechanisms for MLM's to handle DKIM-signed mail. It >> will be true in some cases, and false in others. All for valid reasons >> we should seek to account for. >> > > An MLM in receipt of a properly signed message "from" a domain with ADSP > policy "discard" has a few options: > > 1. Forward the message to the distribution list unaltered, such that the > signature remains intact. This might surprise some recipients, and may be > an exception to normal list policy. On the other hand, it might be feasible > if the list normally doesn't alter the subject or body. > > 2. Break the signature, and forward the message in the knowledge that > recipients may discard it. > > 3. Break the signature, then discard the message. > > 4. Bounce the message, on the grounds that it may not be deliverable once > the signature is broken. The DKIM signature should mean that it's safe to > bounce the message back without risking collateral spamming, at least when > the return path is in the same domain as the "From:" header. > > 5. Reject the message at SMTP time, with an appropriate 5xx error code. > Similar to above. Safer when the return path domain doesn't match the > "from" address domain. > > I don't think I like (2) and (3). I think this helps frame the discussion. It's highly related to Steve's post that Dave so rightly re-posted for re-consideration. People on this list are advocating various options, but oddly enough I think this is the first post on the thread that tried to summarize all options. FWIW, I don't like #2 or #3 either. There's been some debate on this list regarding option #1 and it seems to be a non-starter for MLM operators. Actually, I've recently been joining a lot of new mail lists and some are configured like option #1 and I cannot stand them as a user. So I'd say option #1 might be an elegant/simple solution but I personally wouldn't want to see mail lists behave this way. Options #4 and #5 seem closely related to what Steve was advocating when he brought up the value and role of FBL's could play in the original use case which John L. provided (before I threw in my use case in reaction to Murray's report on MLM re-signing discussions at IETF 77). I think they are all related because they all seem to fall into the category of "I, the MLM, am not going to deliver the mail, but I'm going to provide some failure information to the appropriate parties in the most useful form I can". >From Steve's message: >> Wouldn't >> it be a better idea to avoid the guessing? > > Yes, by notifying all the responsible parties who have set up a > DKIM based FBL and who have valid DKIM signatures on the > message. > > Part of the overhead of handling an FBL is to decide which > reports to pay attention and which aren't. In your case you'd > (probably) want to ignore any reports about mail sent from > your legitimate users via mailing lists, via some heuristic that > works for you. > > But you're the only one who can make that decision, so you > can't push that decision off on to Yahoo or mailing list providers > in general. I don't want them to make the decision to not > send reports to responsible parties who do want the reports > and can handle them. > > It's not too hard for anyone handling inbound FBL streams > to categorize them mechanically, and automate their policies > to ignore reports they believe are irrelevant, so the overhead > for this sort of FBL report is low. If the mailing list manager strips > signatures, they lose a source of data and don't get to make > that decision. > > (As for reputation - a big part of reputation is the content that > is sent. If a particular list subscriber consistently sends mail > that other list subscribers complain about then it's not > unreasonable that that may damage the reputation of
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Apr 30, 2010, at 10:23 AM, Michael Thomas wrote: > On 04/30/2010 07:05 AM, McDowell, Brett wrote: >> >> In that scenario, if the MLM re-signing solution has been deployed by Y, and >> DKIM+ADSP has been deployed by X& Z, and Z has chosen to take action on X's >> ADSP policies... the only thing Z is trusting Y to do is validate incoming >> DKIM signatures, re-sign the messages with its own DKIM signature, and pass >> it along with the A-R results that convey what was done. Z is not trusting >> everything and anything that might ever come through Y. >> >> I think that's a reasonable level of trust to expect mailbox providers to >> have in mail lists who assert that they do this. Rogue mail lists will stop >> being trusted but only after they have "lost" the trust that was granted to >> them via their standards-based assertion (we would probably need to spec out >> how a MLM advertises that they indeed conduct flows in this manner) that >> they perform these functions on incoming mail. >> >> Again, I'm not saying this is the best or most elegant way of handling the >> problem of properly authenticated mail not being able to traverse mail >> lists, but it seems worthy of further discussion as an option. > > Yeahbut... there are zillions of mailing lists out there. How do you know the > good ones > from the bad ones? Keep in mind, of course, that bad guys can resign too, and > they can > easily make themselves look like a mailing list if that's something that > gives them > advantage. Indeed. But mailbox providers all have their own secret sauce for figuring out reputation of senders that I believe they could apply to this new flavor of sender -- meaning MLM's who adopt the MLM-DKIM spec we seem to be debating the virtues of developing -- without too much overhead. > > If the solution is some sort of (third party) reputation/whitelist, then > there's really > not much for us to do, right? I think we still need this spec I'm starting to refer to as MLM-DKIM to specify both the proper way of conducting this re-signing & reporting practice and how the MLM advertises that they follow it. > Even with your discardable adsp setting, it becomes a > matter of the order of checks at the receiver's gate (eg, whitelist first, > then adsp...) > But since mailbox providers already manage reputation at scale, how much of a burden is adding this bit to the mix? Remember this only affects mailbox providers who have decided to do DKIM blocking based on ADSP discardable policies (for some, if not all senders). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] what do mailing lists do, was list vs contributor
On Apr 30, 2010, at 2:24 PM, John Levine wrote: > >> We need to be precise about what we mean by "trustworthy". Even if I >> have "some way to identify trustworthy lists" as you put it above, I >> have to be very clear about what I'm actually trusting that list to do. > > When I sign up for a list, I trust it to send me mail that I am > willing to receive. Is there any other understanding of mailing > lists that people have? > Did you read the rest of my message? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Apr 30, 2010, at 2:31 PM, John Levine wrote: >>> Even with your discardable adsp setting, it becomes a >>> matter of the order of checks at the receiver's gate (eg, whitelist >> first, then adsp...) >> >> But since mailbox providers already manage reputation at scale, how much >> of a burden is adding this bit to the mix? Remember this only affects >> mailbox providers who have decided to do DKIM blocking based on ADSP >> discardable policies (for some, if not all senders). > > You appear to be asking recipients to distinguish among legit directly > sent paypal transaction mail, legit paypal mail that comes through > known-to-be-real mailing lists, and any other paypal mail that is > presumably illegitimate. Nope. I'm suggesting a means for enabling DKIM authenticated mail to survive transit through a mail list and arrive with the intent/purpose/value of the original authentication might be for MLM's to validate incoming mail and DKIM sign their own outbound mail along with the appropriate A-R data. That's all. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
On Apr 30, 2010, at 1:38 PM, Alessandro Vesely wrote: > On 30/Apr/10 12:13, Ian Eiloart wrote: >> --On 28 April 2010 11:02:53 -0400 "MH Michael Hammer (5304)" >> wrote: >>> 2) One possible recommendation to list managers is that if a message to >>> the list is DKIM signed AND has an ADSP discardable policy AND the >>> signature cannot be maintained intact then the list should bounce the >>> message. >> >> +1 > > +1, an additional reason is that the author might have a clever DKIM > configuration, but just forgot to add "[ietf-dkim]" in front of the > subject of a new message. A bounce easily prompts for such correction. > So that's another "vote" for option #4 (per the previous post trying to summarize the various options). BTW, where is this mail list publicly archived? (Next time I'm referring to a previous message I'll just include the URL to the post.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
On Apr 30, 2010, at 12:28 PM, Jeff Macdonald wrote: >>> I'm willing to go from a world where any system can use my From to one >>> where only the systems I say can. And that means changes. >> >> That's an example of the problem in using the term: Much discussion about >> DKIM presume far more end-to-end control by authors or senders than they >> will ever have. > > Murray, John, Dave and Mike: > > I apologize for going off on a tangent. I just keep asking myself "what if". > :) > > I like John's suggestion of taking Brett's ideas to ASRG. Those weren't my ideas. I haven't yet commented on the canonicalization topic. I lost track of who introduced that one. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Apr 30, 2010, at 11:05 AM, Michael Thomas wrote: > On 04/30/2010 07:38 AM, McDowell, Brett wrote: >> On Apr 30, 2010, at 10:23 AM, Michael Thomas wrote: >> >>> On 04/30/2010 07:05 AM, McDowell, Brett wrote: >> But since mailbox providers already manage reputation at scale, how much of >> a burden is adding this bit to the mix? Remember this only affects mailbox >> providers who have decided to do DKIM blocking based on ADSP discardable >> policies (for some, if not all senders). > > Let's put aside whether there's something new here for the moment (i've not > had my > coffee yet...). By all rights, we should not be having this conversation > right now > at all because you have set adsp discardable. So even if we adopted some > bcp-like > advise for mlm and receivers, it would be years if not forever before we > could have > a reliable conversation on this and other lists again. Maybe at paypal that's > an > acceptable tradeoff (?), but at my previous employer, all standards work, for > one, > would cease and there would be lots of engineers with pitchforks and torches. > > So what I'm getting at here is that I'm having a hard time understanding how > the > bootstrap doesn't fail for most sending/receiving entities. As I'm sure you > know, > false positives drive mail admins to complete distraction... which is the > situation > it looks to me that you're willing setting up. > > That said, you (paypal) are far braver than I am, but if you can make this to > work > somehow as a large enterprise that would be a pretty amazing accomplishment. > > Mike Talking about the status quo is to talk about how every ISP/MBP (btw, is it common practice to refer to a "mailbox provider" as a MBP?) has decided to deal with "discardable" ADSP policies given they ALL KNOW that some common Internet practices break DKIM. I'm not sure why that's a useful discussion to have in this forum. I thought we wanted to talk about how to change the status quo so DKIM signatures aren't made irrelevant by common Internet mail practices like MLM's. Just so everyone knows, even some of the ISP/MBP's working with us who are equally committed to curbing paypal.com phishing attacks by means of DKIM and ADSP, are sorting out how they want to handle the gray areas when they see evidence that the message was 'probably validate-able' when it started but something that is 'probably not criminal' happened along the way so I can no longer validate... so let me... make it up as I go and iterate until the standards evolve to remove/reduce this problem. That in fact is why my emails *are* being delivered to at least one gmail.com user on this list. So the status quo is ugly at best. Is there any will in this group (aside from my own) to evolve the standards to improve the status quo? Are the rest of you as concerned about the damage fraud messaging can have to a user's computer, identity, and all systems on the Internet accessible from that computer? I know I don't have to say this, but... this isn't just about stopping annoying ads for viagra. And it isn't just about financial institutions' monetary losses due to account takeover attacks enabled by phishing. It's about the trustworthiness of the Internet and addressing the A#1 channel criminals use today to undermine the integrity of this amazing infrastructure all of us have enjoyed and many of *you* have created. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] besides mailing lists...
On May 3, 2010, at 11:06 AM, MH Michael Hammer (5304) wrote: > And it is easy enough to do "F2F" in a manner that does not break the > authentication-based service. How? -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 10, 2010, at 2:01 PM, Murray S. Kucherawy wrote: > http://datatracker.ietf.org/doc/draft-kucherawy-dkim-lists/ > > Would the WG like to bring it in and make it a WG document? If so, I > volunteer to act as editor. > I'm an IETF newbie, so correct me if I'm wrong. But it seems you are only asking the binary question of whether the WG is willing to add this deliverable to it's scope, with your draft as a strawman, and you acting as the editor. You are not asking us if we have rough consensus on the contents of the document in its current form. Correct? >From what I see on the list, there is clear consensus that this document >should be produced as a WG document (which I support as well). So can we >consider that question closed? Now that it's a WG document, what's the review process... do we just chime in with comments and suggested edits on this thread? -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 20, 2010, at 10:09 AM, MH Michael Hammer (5304) wrote: > If Brett or anyone else has data points that would impact the decision > as to whether the group sticks to a Lists BCP discussion based on > current practice/implementations or sets that aside to modify ADSP, now > is the time to present it. A) I hear you and I'm working on making some confidential data publicly available for the first time. It's more than a notion to achieve, but I'm working on it. But if folks don't trust my anecdotal evidence/use case, why would they trust my data? B) I'm going to re-subscribe to this (and all outside-the-firewall mailing lists) with a personal email address to avoid the current situation (of my messages going to SPAM or the bit bucket due to the firm ADSP=discardable policy on paypal.com and MLM's inability to sustain DKIM signatures in a form receivers need to see it in order to verify the paypal.com signature). It's a temporary work-around and we are developing a long-term solution for our employees that I'll write about once it's live so other ADSP=discardable organization can learn from our experience. C) I don't know if this list is the right place to discuss updating/expanding ADSP, but it is absolutely related and important in the big picture. That said, I agree the BCP for MLM's is separate and needs to be published for the world as it is today, or it won't be published for quite some time. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sep 4, 2010, at 9:31 PM, Steve Atkins wrote: > The whole point of rotating keys is so that loss of an old private key > isn't a risk. Given that, I think that even if you're fairly sure that a key > pair hasn't been compromised then you should remove the public > key as soon as is reasonable after you stop signing with the private > key - as the private key continues to be a high value target until > the public key is removed. > > Eight days is as short as I'm comfortable with, so that's as soon > as is reasonable for me. ...but what would be "as long as I'm comfortable with"? Have we seen DKIM private keys compromised due in large part to leaving the public keys in rotation for too long... and what was "too long" in those instances. I'd be surprised to discover many senders are rotating keys every eight days. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Key rotation
On Sep 9, 2010, at 2:26 PM, Steve Atkins wrote: > > On Sep 9, 2010, at 11:12 AM, McDowell, Brett wrote: > >> I'd be surprised to discover many senders are rotating keys every eight days. > > I didn't suggest rotating keys every eight days. Rather, I suggested leaving > the public keys in place for 8 days after removing the associated private key. My apologies, I completely misunderstood what you were suggesting in this thread. But at least now I know you aren't crazy (at least not for your position on this issue ;-) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 13, 2010, at 10:10 AM, John R. Levine wrote: >> What ADSP users want is irrelevant. This is about what MLMs want (which is >> most likely to ensure that submitted messages reach the whole of their >> list without problems). > > Right. The easiest way to do so, assuming you believe that enough people > will use ADSP to matter, is to discard incoming messages with ADSP > settings that can cause trouble. If they say their mail is discardable, > take them at their word and discard it. I disagree. The ADSP=discardable deployer is not conveying apathy regarding the deliverability of their mail, quite the opposite IMO. They are saying (to paraphrase) "please attempt to verify the DKIM signature on this message against the key record in our DNS for this domain/subdomain, and if you cannot verify the signature then please discard the message as a means of protecting your subscriber from phishing attacks, otherwise please deliver the message and do so knowing we put this much effort into ensuring the goodness of the mail before we sent it". -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 9:15 AM, Hector Santos wrote: > Ian Eiloart wrote: > >> If the MLM owner knowingly breaks a signature, and either discards the >> message or forwards it into a system that is likely to discard it, and do >> not notify the sender, then the forwarder must be responsible for any harm >> done. They really should reject such messages. > > +1 and nothing short of this is just poor mail system integration and > product engineering. +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 9:31 AM, MH Michael Hammer (5304) wrote: > > >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of John R. Levine >> Sent: Tuesday, September 14, 2010 9:18 AM >> To: Ian Eiloart >> Cc: DKIM >> Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review >> >>> There are all sorts of reasons for publishing ADSP=discarable, from > "the >>> domain isn't used to send email" (analagous to "spf -all") >> >> Quite right, in which case I hope you'll agree that throwing mail away > is >> exactly the right thing to do. >> >>> to "our domain is widely spoofed (because of its sensitive nature), > and >>> we absolutely do sign all our email". >> >> That would be dkim=all, not dkim=discardable. >> >> As I keep saying over and over, discardable really means discardable: > if >> in doubt, throw it away. It does NOT, repeat NOT, mean high value > mail. >> It means low value mail. >> > > -1 > > It does not mean low value mail and I don't think you will find a > sending mplementing dkim=discardable that would agree with you. In the > case of the domain actually sending mail, what is being said is that the > risk of phishing/badness/abuse is great enough that when in doubt, > discard it if it fails to validate or does not have a signature. This is > significantly different than "it means low value mail". > > Mike I agree with Mike's assessment. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 10:32 AM, John R. Levine wrote: >> It does not mean low value mail and I don't think you will find a >> sending mplementing dkim=discardable that would agree with you. > > Then in the RFC we utterly failed to make it clear what dkim=discardable > means. Sigh. > > Once again, we see that ADSP is so broken that even people who like it > don't understand what it is for. > > R's, But John, you clearly never wanted ADSP to exist and you've made enough statements publicly about your motivation for becoming a co-author that it should come as no surprise if folks don't interpret your comments regarding ADSP with the same deference one normally expects in response to comments coming from a co-author. I suspect your fellow authors didn't realize you'd use this label change of "discardable" as ammunition after-the-fact to lobby for ADSP's disuse. Perhaps it's time to issue an update to ADSP which clarifies how the spec should be interpreted, by those who actually use it. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 11:13 AM, John R. Levine wrote: >> I agree with Mike's assessment. > > I remain unable to reconcile "this is very important" and "throw it away" > applied to the same message. > Scott nailed it when he said: This means they view the risks of having legitimate mail discarded as lower than the risks associated with having unsigned mail delivered. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 13, 2010, at 5:30 PM, Douglas Otis wrote: > On 9/13/10 1:03 PM, McDowell, Brett wrote: >> The ADSP=discardable deployer is not conveying apathy regarding the >> deliverability of their mail, quite the opposite IMO. They are saying (to >> paraphrase) "please attempt to verify the DKIM signature on this message >> against the key record in our DNS for this domain/subdomain, and if you >> cannot verify the signature then please discard the message as a means of >> protecting your subscriber from phishing attacks, otherwise please deliver >> the message and do so knowing we put this much effort into ensuring the >> goodness of the mail before we sent it" > For MLMs making modifications that invalidate DKIM signatures, posting > should be blocked for domains making an ADSP dkim=discardable > assertion. Such an assertion might cause other subscribers to refuse > messages from an Author Domain with the discardable assertion and cause > delivery and message queuing to be problematic. Otherwise, those > refusing these messages run a risk of being unsubscribed. That would be an undesired outcome and therefore a "reject" by the MLM would be more appropriate (until we have a RFC in place and adopted that enables the "transient trust"/"chain of trust" notion I've been advocating for). And yes, I'm going to write one but perhaps only after I work with more mailbox providers to implement the notion now. > > -Doug > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 13, 2010, at 8:43 PM, John R. Levine wrote: >> But if that stuff was signed before entering our whatevers, how can we >> verify the signature when pulling it out? This question may entirely >> invalidate assumptions that nobody ever actually made about somebody >> else's theoretical wiping policy! > > Not to stretch this metaphor too far, but I believe that the assertion > that people care whether mail inbound to MLMs was signed remains utterly > unsupported. I support it, in the context of supporting the "transient trust" use case (aka the A-R approach). > > Give the IETF's traditions, the usual way to show that you care about > something is to write the code to do it. So if you don't write code for senders you aren't allowed to express an opinion about sender policy? That's just silly. We are all stakeholders in this ecosystem and we all have a right to our opinion and perspective, regardless of how we engage/influence the Internet Mail ecosystem. > For the lists I run, I've > modified MJ2 to put a signature on outgoing mail with the list's domain > and a private field to say which list it was. I can't say I've seen any > improvement in delivery which was already close to 100%, but it certainly > hasn't hurt anything and it's made it easier to process Yahoo FBLs. > That's one of the reasons I'd want a list BCP to tell lists to sign their > mail; I've tried it, albeit at small scale, and it works. We know from > reports that at least one MTA misimplements ADSP to reject on discardable > failures, which suggests that a robust MLM should be prepared to deal with > that, most simply by pre-discarding anything that might cause that > problem. I haven't implemented that because, so far at least, none of my > susbcribers appear to use ADSP so it's pretty low on my list of things to > worry about. > > Based on recent correspondence, it appears that one of the most vehement > advocates of modifying MLMs to work around ADSP and to pass through info > to retroactively check contributor signatures hadn't noticed that I put > S/MIME signatures on my list mail and that even though it adds a footer to > each message, Mailman passes the signatures through so his MUA can verify > them. Care? Get real. You lost me. > > R's, > John > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 9:40 AM, Scott Kitterman wrote: > On Tuesday, September 14, 2010 09:18:23 am John R. Levine wrote: >> As I keep saying over and over, discardable really means discardable: if >> in doubt, throw it away. It does NOT, repeat NOT, mean high value mail. >> It means low value mail. > > I think your view is to narrow. It means that the domain owner prefers it be > discarded if not signed. This means they view the risks of having legitimate > mail discarded as lower than the risks associated with having unsigned mail > delivered. Agreed. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
...and implement what you think should work before making an issue of it in IETF. That's been my #1 lesson this year (I'm new to IETF). I originally was actually worried about blowback by the community if a large entity like ourselves and few other household names just went off and deployed something with capabilities that overlap with proposals being floated in the IETF, without participating in those debates or aligning with those proposals. But what everyone has been telling me is that it would be better in fact to go and deploy something before drafting the I-D and debating it here. This is the main reason why I went quiet on these lists since the Barcelona MAAWG meeting (until this week). On Sep 14, 2010, at 3:35 PM, J.D. Falk wrote: > ...but not for the reasons the anti-ADSP folks keep bringing up. > > DKIM is failing because every discussion about actually /using/ DKIM > inevitably gets stuck in the same old argument about ADSP. Doesn't even > matter what the argument is about anymore; it stops all forward progress > every time. And we keep letting it happen -- actively participating, even, > including me. > > Continuing to argue these same points over and over is disrespectful of our > colleagues both on and off this list, and of the IETF process. > > So I'm going to stop, and I beg you all to join me. > > Stop arguing, and start writing drafts. Let us discuss the drafts instead of > attacking each others' intractable positions for the Nth time. If you think > ADSP will bring about the end of all human communication, WRITE A DRAFT > EXPLAINING WHY. If you think something else, write that instead. > > Yes, I know it requires more effort, but what we've been doing so far clearly > isn't working. > > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] In the spirit of moving forward...
It was my understanding that the MLM BCP was intended to inform MLM operators of what they should do with DKIM-signed mail. Since that is the critical question, I would assert we need rough consensus on the answer to that question before issuing a WGLC on the document. I do not believe we have rough consensus on the answer to that question, i.e. reject vs. discard vs. bounce nor strip-and-sign, change from: and sign, or just simply re-sign as-is nor what to do about/with A-R. Correct me if I'm wrong about that, but I saw some of those issues raised just this week (and we were debating these same issues in May). On Sep 15, 2010, at 12:24 AM, Murray S. Kucherawy wrote: > There was very little response to my last straw poll about where we go with > the MLM draft next. It certainly wasn't enough to be able to claim "rough > consensus" from a group this size. > > I have some feedback on the actual text from Jeff, Daniel and Dave to > incorporate, and I haven't forgotten that. But there remains the issue of > whether or not to split it into two or three documents covering specific > topics (a non-DKIM MLM BCP, a DKIM-specific MLM BCP, and a DKIM value-add for > MLMs informational), and whether or not to just drop the whole affair because > there's not enough we can really say anyway. > > Given my druthers I'd like to proceed with it the way it is since absent > rough consensus to change course, the right thing to do seems to be to press > on. (After thinking about that a bit, I have to admit that it's also the > most attractive to me since it's the least amount of work...) > > Is anybody going to be really upset if I go that route and then work toward a > WGLC later this year? > > -MSK > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
On Sep 15, 2010, at 12:11 AM, Murray S. Kucherawy wrote: > Based on that (rather precise) description, aren't ADSP's requirements a > proper subset of the DKIM requirements? If so, I'm not sure I agree with > "badly conflicting", but it does frame future discussion quite nicely. > > For example, if DKIM enables the identification of mail streams, isn't the > one ADSP covers just a specific instance of a mail stream? > BTW, one thing I think we can agree on and find value from in these pre-deployment email discussions is terminology. I ran into a problem at the last MAAWG during a panel discussion where my understanding of "3rd-party signature" is what someone else meant by "2nd-party signature". What is the real definitions of "1st-party", "2nd-party" and "3rd-party" signatures in the context of DKIM and ADSP, i.e. in the context of i= and d= and from: values? > > From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On > Behalf Of Steve Atkins [st...@wordtothewise.com] > Sent: Tuesday, September 14, 2010 3:01 PM > To: DKIM List > Subject: Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault > > The problem is that the two things have badly conflicting requirements. DKIM > is based on a domain-based identifier that's independent of the From: domain, > and that's where much of it's value comes from. ADSP is based on a > domain-based identifier that must remain identical to the From: field at all > times, and that's where it's sole value comes from. ADSP intrinsically > conflicts with the original design case for DKIM, despite being piggy-backed > on to it. > > So any document that puts forth even basic good practices for DKIM usage for > monitoring sender reputation (use d= to differentiate mail streams) is going > to be anathema to ADSP requirements (d= must be the same as the From: domain). > > And any ADSP-driven set of requirements (mailing lists should not only > re-sign any mail they re-send, they should alter the From: address to match) > is going to be considered nonsensical by people who consider DKIM a way to > tie an identity cookie to a message. > > And, as we've seen, any compromise document is hated by pretty much everyone, > even assuming you can get there. > > Cheers, > Steve > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
On Sep 15, 2010, at 11:02 AM, Jeff Macdonald wrote: > On Wed, Sep 15, 2010 at 10:43 AM, McDowell, Brett > wrote: >> On Sep 15, 2010, at 12:11 AM, Murray S. Kucherawy wrote: >> >>> Based on that (rather precise) description, aren't ADSP's requirements a >>> proper subset of the DKIM requirements? If so, I'm not sure I agree with >>> "badly conflicting", but it does frame future discussion quite nicely. >>> >>> For example, if DKIM enables the identification of mail streams, isn't the >>> one ADSP covers just a specific instance of a mail stream? >>> >> >> BTW, one thing I think we can agree on and find value from in these >> pre-deployment email discussions is terminology. I ran into a problem at >> the last MAAWG during a panel discussion where my understanding of >> "3rd-party signature" is what someone else meant by "2nd-party signature". >> What is the real definitions of "1st-party", "2nd-party" and "3rd-party" >> signatures in the context of DKIM and ADSP, i.e. in the context of i= and d= >> and from: values? > > I believe only the ADSP documents talk about 3rd party, and it is > defined as d= not From Domain. > > These are 3rd party: > > DKIM-Sig: ... d=dkim.bar.com > From: f...@bar.com > > DKIM-Sig: ... d=beer.com > From: f...@bar.com > > I believe Patrick defined 2nd party to be: > DKIM-Sig: ... d=dkim.bar.com > From: f...@bar.com > > the maawg meeting was a first that I've heard that. > > First party is of course: > > DKIM-Sig: ... d=bar.com > From: f...@bar.com > > > BUT I really thinking making such distinctions is the wrong approach. > It really doesn't matter what type of signature it is. I'd even > advocate for a DKIM update that would cause all signatures to be 2nd > or 3rd to enforce the point. > That seems aligned with Steve's point about DKIM's value coming (only?) when the d= value is not the same as the domain-name in the from: field. So according to you (and Steve?) the IETF should pass a normative requirement that all verified email be hired out to 3rd parties?! That strikes me as very anti-Internet. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
(sorry Stephen, but I had to reply to this one) On Sep 15, 2010, at 12:01 PM, Steve Atkins wrote: >> That seems aligned with Steve's point about DKIM's value coming (only?) when >> the d= value is not the same as the domain-name in the from: field. So >> according to you (and Steve?) the IETF should pass a normative requirement >> that all verified email be hired out to 3rd parties?! That strikes me as >> very anti-Internet. > > I think you're not reading carefully, and you're twisting Jeff's words and > mine to a point that bears no resemblance to what either of us said. As it turns out, you are completely correct and I withdraw that comment. It just shows how entirely confused I was about what you and Jeff meant by 3rd-party signatures (which Jeff clarified in his response). Jeff's definition of 3rd-party signature is entirely different from what I thought it meant (and what other experts have responded to me with off-list BTW). I've taken this conversation off-list. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871 interoperability conflict over "h= " tag
(if this doesn't belong on this list, please let me know) RFC 4871 states: > h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to >allowing all algorithms). A colon-separated list of hash >algorithms that might be used. Signers and Verifiers MUST >support the "sha256" hash algorithm. Verifiers MUST also support >the "sha1" hash algorithm. We have a DKIM-signed mail stream that is "passing" with Receiver1 but failing with Receiver2 and it's Receiver2 who has a "new" interpretation of the requirement above. Here are the two interpretations, please let me know which is generally considered correct (of if both are wrong): Interpretation #1: The sender must support both, but doesn't need to use both. It could be h=sha1, h=sha256, h=sha1:sha256, or h=*. The receiver however MUST support either. Therefore the receiver should be not fail verification just because the explicit tag in the DNS record says "h=sha1" instead of the "h=sha1:sha256" which is expected. Interpretation #2: The sender must support both, which means the sender must either not have an h= tag in the DNS record (defaulting to h=sha1:sha256) or it must explicitly list "h=sha1:sha256" and therefore the sender should adjust their public key records vs. the receiver adjusting their infrastructure to verify "h=sha1" (btw, this is for messages that contain "a=rsa-sha1" in the DKIM-Signature header). I may have provided both too much and too little information, but this is the interoperability problem we are facing at the moment. Comments? Many thanks! -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871 interoperability conflict over "h= " tag
Thank you both for your input. To summarize... a receiver should not fail a message simply because the sender has "h=sha1" in their DNS and "a=rsa-sha1" on their signatures, even though that particular configuration isn't exactly expected by an acutely accurate reader of the RFC. Yes? On Jan 11, 2011, at 6:30 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of McDowell, Brett >> Sent: Tuesday, January 11, 2011 2:33 PM >> To: ietf-dkim@mipassoc.org WG >> Subject: [ietf-dkim] RFC4871 interoperability conflict over "h= " tag >> >> (if this doesn't belong on this list, please let me know) >> >> RFC 4871 states: >> >>> h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to >>> allowing all algorithms). A colon-separated list of hash >>> algorithms that might be used. Signers and Verifiers MUST >>> support the "sha256" hash algorithm. Verifiers MUST also support >>> the "sha1" hash algorithm. > > The "a=" value indicates a signature generation algorithm, and the definition > of that algorithm indicates which hash (message digest) method was used as > part of that algorithm. Thus, in essence, the "a=" in the message and the > "h=" in the key have to line up for verification to complete. > > For example, if you send me a message signed with "a=rsa-sha1", then when I > retrieve your key, I expect to see no "h=" value there, or a value that > includes "sha1". > >> Interpretation #1: The sender must support both, but doesn't need to >> use both. It could be h=sha1, h=sha256, h=sha1:sha256, or h=*. The >> receiver however MUST support either. Therefore the receiver should be >> not fail verification just because the explicit tag in the DNS record >> says "h=sha1" instead of the "h=sha1:sha256" which is expected. > > You're saying a bunch of different things here: > > "The sender must support both, but doesn't need to use both." True. > > "It could be h=sha1, h=sha256, h=sha1:sha256, or h=*." True except the last, > as "*" isn't valid by that tag's ABNF. > > "The receiver however MUST support either." True, inasmuch as "either" is a > subset of "both". :-) > > "Therefore..." Depends on the signature. If the record says "h=sha1" but > the signature says "a=rsa-sha256", I'd fail it. > >> Interpretation #2: The sender must support both, which means the >> sender must either not have an h= tag in the DNS record (defaulting to >> h=sha1:sha256) or it must explicitly list "h=sha1:sha256" and therefore >> the sender should adjust their public key records vs. the receiver >> adjusting their infrastructure to verify "h=sha1" (btw, this is for >> messages that contain "a=rsa-sha1" in the DKIM-Signature header). > > I think you're mixing implementation with policy. The "h=" tag in a key > record is an expression of policy that this key can only be used with the > specified hashes. It is not a statement of what the signer implements. > > -MSK > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Full name problem
On Mar 2, 2011, at 3:19 AM, Michael Deutschmann wrote: > 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. I'm not sure who can say whether or not this will help until sufficient usability testings has been done. > 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. That's another idea that could/should be tested. The point being made on this thread is one I share, i.e. the MUA has a role to play as an active client in email authentication scenarios. That's not yet a consensus, but the concept is gaining momentum. It comes down to usability testing, useful metrics, and peer-reviewed data analysis. Then we should really know what we should be doing with the MUA, if anything. All that said, I don't believe MUA behavior is in scope for this IETF WG. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
On Mar 30, 2011, at 11:49 PM, Jim Fenton wrote: >> . Goodmail .. >> . . >> V V >> Client -> Mail -> Transfer -> Service -> Receiver -> Recipient >> >> Goodmail interacted with the creator of the document and, separately, >> with the receiving mail service, as an adjunct "back office" service. >> To repeat: /It was not in the direct handling path./ >> >> DKIM supports that mode of operation quite nicely and it is a >> particularly powerful operational mode, so it is worth keeping that >> "configuration" in mind explicitly. Given how persistent this >> confusion seems to be it might even be worth more language, though I'm >> not coming up with a suggestion, offhand. > > This still seems to me to be too specialized a use case to list in the > specification, but would look to WG consensus on which way to go here. I agree. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
On Apr 3, 2011, at 5:12 PM, Dave CROCKER wrote: > OK. So the capability exists, but people choose not to use it. Some people > in > fact choose to disable this capability; note that a) ADSP is an add-on, not > the > DKIM core, and b) the actual uptake of ADSP on the receive side is not known > to > be large. One new-ish data point: I believe Hotmail is leveraging the ADSP records from domains they trust to be operating with consistency. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
On Apr 4, 2011, at 12:09 AM, John Levine wrote: > If there is a reason why people aren't able to use a d= domain per > stream, I wish someone would explain in simple terms that even a > dimwit like me can understand. > > The only arguments I'm aware of is that hostile or incompetent DNS > managers refuse to install key records, which isn't a very good reason > to add cruft to a standard > and "I want to do it some other way" which > is even worse. Characterizing our 'customers' for this standard as "hostile or incompetent" doesn't seem like posturing ourselves for success. There are deployment considerations that impact adoption of many (all?) technical standards. We ignore them at our peril. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
I believe the context for your earlier comments that I responded to was the discussion about deprecating i= and/or adding a new st= tag. I hope my comments were not interpreted as supporting either of those changes. That was not my intention. On Apr 4, 2011, at 10:47 AM, John R. Levine wrote: > I think it would be a fine idea to come up with tools to help maintain the > necessary DNS records. Agreed. But probably out-of-scope for this WG, yes? MAAWG, OTA, BITS, APWG, etc. seem like better fora for this kind of deployment support. > In the small scale at least, I can report that > it's very simple and my monthly DKIM key rotation is completely automated. > Large organizations have larger issues, Indeed, and those differences are not to be underestimated. I've been surprised to hear from other deployers just how hard this for them to operationalize at scale. These are folks who generally don't participate in IETF so we don't see a lot of first-hand reports on this mail list (at least I haven't). > but the right thing to do is to > help to deal with the problem. ... and the root cause of the problem, which just might be a missed opportunity to optimize something in the spec itself. I was only chiming in for the sake of keeping our tone open to specification changes based on real world deployment challenges (at least for the remaining duration of this WG). But here's where I agree with John: we haven't seen any deployment challenges documented in an actionable way that would suggest specification changes. There's a lot of anecdotal evidence (like what I share above ;-) but not much actionable detail. -- Brett ___ 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
Will your "assume one more From than listed in h=" lead to failed verifications on messages that actually follow the advice in the RFC to list duplicate headers in their h= values? > -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Scott Kitterman > Sent: Thursday, July 07, 2011 12:44 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Final update to 4871bis for working group review > > On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote: > > > -Original Message- > > > From: ietf-dkim-boun...@mipassoc.org > > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman > > > Sent: Thursday, July 07, 2011 6:32 AM > > > To: ietf-dkim@mipassoc.org > > > Subject: Re: [ietf-dkim] Final update to 4871bis for working group > > > review > > > > > > I'm working with someone on an implementation and I think we're > > > going to assume one more From than listed in h= when verifying to > > > ensure nothing has been added. > > > > This intentionally causes the verifier to assume what the signer > > really meant when it signed a message using a single From: field. > > That may look safe but it isn't what DKIM actually says. > > > > We might do this for libopendkim somewhere down the line, but it would > > default "off". > > > > In any case, interesting idea. > > It only assumes that the signer signed all the From: fields present in the > message (note: I said one more than in h=, not two). I think it's fair to say > that if someone is sending messages with multiple From: fields (or > Date:/Subject:) and trying to sign something less than all of them they are > fairly deep into unsupported territory and shouldn't find any result > surprising. > > I agree it's not exactly what is specified in the protocol, but this is an > implementation design issue. I think it's safe. If the DKIM protocol says I > can't do something like this, then I think we have a problem with the current > "describe it and let implementors deal with it" plan. > > Scott K > ___ > NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list- > rules.html ___ 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
I would agree with your statement if you put the word "deployers" between DKIM and MUST. > -Original Message- > Unfortunately, the norm is not to make these checks because only DKIM > invites the possible exploit. DKIM MUST accept the role of preventing the > exploit it invites. ___ 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
> -Original Message- > From: John Levine [mailto:jo...@iecc.com] > Sent: Thursday, July 07, 2011 6:22 PM > > >Will your "assume one more From than listed in h=" lead to failed > >verifications on messages that actually follow the advice in the RFC to > >list duplicate headers in their h= values? > > The RFC also says you shouldn't sign messages that aren't RFC 2822. So pick > your poison. > > I have to say it's a little surreal to have these arguments about what changes John, this particular part of the discussion is not about changing the RFC or DKIM implementations, only changing deployment configuration practices. > to make to avoid the horrors of a duplicate From: attack that is and likely > will > always be entirely hypothetical, Doug, has Trend Micro actually demonstrated this attack (and the recommended counter measures) on the wire? If not, I suggest you do so. ___ 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
-1 --- Sent from my mobile phone On Jul 10, 2011, at 3:58 AM, "Michael Deutschmann" wrote: > 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
