Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list
On 23 Jun 2011, at 20:00, Douglas Otis wrote: This seems like a completely bogus argument to me. You're saying that some domains can't be trusted, therefore none can be trusted. That's a logical fallacy. Not at all. Acceptance policies and results for DKIM MUST align with what is being displayed in the message. Otherwise malefactors may be able to exploit open and large volume domain's signatures and their lack of duplicates in the signed header list (which most don't do). The pre-pended header fields could then be that of any high value domain. These messages might have been accepted on the false premise of being from a high volume domain when based upon valid DKIM signature indications. Right, but DKIM is checked at the MTA. If I think that messages DKIM signed by, say, my local council, are trustworthy, then I apply a spam score accordingly. The fact that someone else might spoof a From: header in a different mail stream says nothing about whether I can trust the stream from my local council. So, it may be that the practical outcome is to improve the deliverability of mail for a trusted signer, which is a different problem. But that's still useful. With ADSP, of course, there's also a chance of spotting spoofed messages. And, if multiple From: headers become a popular spoofing mechanism, I guess sites will stop accepting them. I accept that DKIM doesn't solve every problem, but that doesn't mean that it has no value. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list
On 24 Jun 2011, at 05:55, John R. Levine wrote: Assuming this is some other protocol layers problem; to ensure consistency between any possible display and DKIM validation, ... ... is, for about the hundredth time, not DKIM's job. Please chant we have no idea how MUAs will display mail over and over until you believe it. This includes valid 5322 mail. So, heck, what's the point in validating anything? After all, the MUA may simply display this message as a link to a canadian pharm site! I think we can be pretty sure that - if there's only one From: header - then the MUA won't display an unsigned From: header in preference to a signed one. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list
On 24 Jun 2011, at 03:46, Douglas Otis wrote: On 6/23/11 2:52 PM, John R. Levine wrote: Acceptance policies and results for DKIM MUST align with what is being displayed in the message. I'm pretty sure that we have uniformly agreed not to attempt to do MUA design, so, no, it doesn't. We have no idea what is displayed in the message. We have no idea if the message will ever be displayed at all. Ian, John is right. Most headers are displayed selecting top-down and DKIM always selects bottom-up. Headers likely displayed and selected to be signed need to be check by some protocol layer that ensures they are not illegally pre-pended. Unfortunately, both SMTP and DKIM will not make these basic checks. There seems to be a prevailing assumption undefined spam filters will instead intercede. Who should victims blame when these checks are not made? They should blame (a) the spammer, and (b) their local MTA operator. Even though we don't do MUA design, somebody has to. It's helpful if there's a set of people in the world that have considered these issues, and can give advice on them. How can a secure system be specified? With this particular issue, it seems that an MTA could simply insist that a message comply with RFC5322's requirement that there be exactly one From: header. Now, we could say in DKIM that a signature is invalid if there's more than one From: header present in the message. Or we could informally advise MTA or MUA designers that ignoring RFC5322's requirements here is inadvisable, since DKIM has that assumption. For me, as an MTA operator, I'm happy that I have justification for rejecting messages with the wrong number of From: headers. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ 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
For me, as an MTA operator, I'm happy that I have justification for rejecting messages with the wrong number of From: headers. I have pointed out at least six times, that in the extremely unlikely event that bad guys were to send mail with double From headers you can just dump it, since no real mail has more than one. You don't need DKIM for that. Spam filters have detected spam by looking for technical message flaws for over a decade, and this is just another one. I don't know how to say that any more clearly. Perhaps you can explain it to Doug. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list
On Fri, 24 Jun 2011 05:55:38 +0100, John R. Levine jo...@iecc.com wrote: Assuming this is some other protocol layers problem; to ensure consistency between any possible display and DKIM validation, ... ... is, for about the hundredth time, not DKIM's job. Please chant we have no idea how MUAs will display mail over and over until you believe it. This includes valid 5322 mail. Precisely so. Which is why, this being a secuity protocol, we have to presume that MUAs will do whatever will make life most difficult from a DKIM POV, and design a protocol which works in spite of that. This we have signally failed to do. In the present situation, we need to presume that MUAs will display the first instance only of any duplicated header (which is a pretty safe presumption given that the most communly used MUA does just that). The AD has been made aware of this problem, and has concluded that the present 3.8 will suffice (though he has caused a missing reference to the proper oart of section 8 to be added). Whilst I disagree with his conclusion, I have decided not to take the matter any further (and Doug and Rolf are aware of my decision). -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] spam filtering 101, was DKIM expert group meeting for Dutch 'comply or explain' list
On 6/24/2011 5:55 AM, John R. Levine wrote: For me, as an MTA operator, I'm happy that I have justification for rejecting messages with the wrong number of From: headers. I have pointed out at least six times, ... 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. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Mostly off topic: For Ian Eiloart
Ian's MTA has a buggy callback system that tries to use fake bounces to guess whether a sending address existed. I thought these had been stamped out due to both the fact that they mostly attack innocent bystanders, and the fact that they don't work, but I guess not yet. R's, John i...@sussex.ac.uk: 139.184.14.92 does not like recipient. Remote host said: 550-5.1.7 Verification failed for jo...@iecc.com 550-5.1.7 Called: 64.57.183.56 550-5.1.7 Sent: RCPT TO:jo...@iecc.com 550-5.1.7 Response: 553 Not our message (5.7.1) 550-5.1.7 sender verification failed for jo...@iecc.com 550-5.1.7 see http://www.sussex.ac.uk/its/helpdesk/faq.php?faqid=1101 550 5.1.7 the mail server for iecc.com denied the existence of jo...@iecc.com. Giving up on 139.184.14.92.ietf-d...@mipassoc.org ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
On 6/23/11 8:24 AM, John Levine wrote: In article4e02ee24.2060...@gmail.com you write: On 6/22/11 11:14 AM, Dave CROCKER wrote: Folks, The bottom line about Doug's note is that the working group extensively considered the basic issue of multiple From: header fields and Doug is raising nothing new about the topic. Dave is quite right. Doug's purported attack just describes one of the endless ways that a string of bytes could be not quite a valid 5322 message, which might display in some mail programs in ways that some people might consider misleading. If it's a problem at all, it's not a DKIM problem. Perhaps you can explain why the motivation stated in RFC4686 includes anti-phishing as DKIM's goal? Why of all the possible headers ONLY the From header field MUST be signed? Why RFC5617 describes the From header field as the Author Author address that is positively confirmed simply with a Valid DKIM signature result? Both RFC4686 and RFC5617 overlooked a rather obvious threat clearly demonstrated by Hector Santos on the DKIM mailing list: Pre-pended singleton header fields. Neither SMTP nor DKIM check for an invalid number of singleton header fields. These few header fields are limited to one because they are commonly displayed. Multiple occurrence of any of these headers is likely deceptive, especially in DKIM's case. DKIM always selects header fields from the bottom-up, but most sorting and displaying functions go top-down selection. Complaints from John, Dave, and Barry and others is likely and understandably out of fatigue. They just want the process to be over. We are now hearing there is a vital protocol layering principle at stake which even precludes DKIM from making these checks! Really? Although DKIM will be securely hashing the headers fields which MUST include the From header, developers are being told they must ignore multiple singleton header fields discovered in the process. It is not their burden! As if securely hashing, fetching any number of public keys, and verifying any number of signatures isn't? -Doug ___ 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-13.txt
-Original Message- From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Friday, June 24, 2011 12:08 PM To: i-d-annou...@ietf.org Cc: ietf-dkim@mipassoc.org Subject: I-D Action: draft-ietf-dkim-rfc4871bis-13.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : DomainKeys Identified Mail (DKIM) Signatures Author(s) : D. Crocker Tony Hansen M. Kucherawy Filename: draft-ietf-dkim-rfc4871bis-13.txt Pages : 78 Date: 2011-06-24 [...] IESG-requested tweaks only, plus an IPR statement adjustment since we don't yet have consent from all of the RFC4871 authors. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
On Jun 24, 2011, at 10:33 AM, Douglas Otis wrote: Complaints from John, Dave, and Barry and others is likely and understandably out of fatigue. They just want the process to be over. We are now hearing there is a vital protocol layering principle at stake which even precludes DKIM from making these checks! Really? While people are tired of you, fatigue is not the issue. Rather it's that you either don't appear to accept the fact that very few people agree with you, rather you continue to bring up exactly the same issues repeatedly, even though you know you're not going to convince anyone by that repetition, as they've explained to you in detail, repeatedly why your concerns are unfounded. That ends up consuming many peoples time to no good result. Your current argument is of the form: Doug: X is bad, and could theoretically lead to end-user confusion in one particular obscure replay scenario, given a carefully chosen set of assumptions about MUA user interface design. World: Yes, X is bad, but it's out of scope for the DKIM protocol, as it's nothing to do with DKIM, rather it's a violation of 5322. World: Spam filters and MTAs should certainly consider it, though. World: Heck, DKIM *implementations* probably should, even though it's not part of the DKIM protocol - other than DKIM applies to email, and data streams with X are not email. Doug: If it's not in the DKIM protocol, then we are telling the entire world that they MUST NOT pay attention to X anywhere in their mail handling process... World: Uhm... what? No, we're not. That's just rid Doug: and that makes DKIM worthless! World: Uhm... what? No, that's not what we said. Repeat, ad- nauseam and beyond. (Attempting to drum up support in other fora after you've failed to get it here, presumably in the hopes of gaining supporters who'll come here to continue the good fight seems unlikely to benefit anyone involved, either.) Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
On 6/24/11 2:43 PM, Steve Atkins wrote: On Jun 24, 2011, at 10:33 AM, Douglas Otis wrote: Complaints from John, Dave, and Barry and others is likely and understandably out of fatigue. They just want the process to be over. We are now hearing there is a vital protocol layering principle at stake which even precludes DKIM from making these checks! Really? While people are tired of you, fatigue is not the issue. Rather it's that you either don't appear to accept the fact that very few people agree with you, rather you continue to bring up exactly the same issues repeatedly, even though you know you're not going to convince anyone by that repetition, as they've explained to you in detail, repeatedly why your concerns are unfounded. That ends up consuming many peoples time to no good result. Your current argument is of the form: Doug: X is bad, and could theoretically lead to end-user confusion in one particular obscure replay scenario, given a carefully chosen set of assumptions about MUA user interface design. World: Yes, X is bad, but it's out of scope for the DKIM protocol, as it's nothing to do with DKIM, rather it's a violation of 5322. World: Spam filters and MTAs should certainly consider it, though. World: Heck, DKIM *implementations* probably should, even though it's not part of the DKIM protocol - other than DKIM applies to email, and data streams with X are not email. Doug: If it's not in the DKIM protocol, then we are telling the entire world that they MUST NOT pay attention to X anywhere in their mail handling process... World: Uhm... what? No, we're not. That's just rid Doug: and that makes DKIM worthless! World: Uhm... what? No, that's not what we said. Repeat, ad- nauseam and beyond. Steve and Dave, Allow me to bring up a few new (albeit related) issues then. ADSP (RFC5617) depends upon DKIM's output. ADSP failed to consider a pre-pended header threat. When present, this unchecked threat means the Author Address is undefined. Those trusting ADSP results are placed at risk due to a lack of assurance pre-pended header fields were excluded. Message Header Field for Indicating Message Authentication Status (RFC5451) also depends upon DKIM's output. This specification also failed to consider a pre-pended header threat. When present, this specification lacks signaling to indicate whether signed singleton header field replicates were excluded and of course the header.from is undefined. Those trusting an Authentication-Results header field are placed at risk due to the lack of assurances that pre-pended header fields were excluded. Does this avoid the out-of-scope claim being repeated ad-nauseam? -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
On Jun 24, 2011, at 4:04 PM, Douglas Otis wrote: On 6/24/11 2:43 PM, Steve Atkins wrote: Your current argument is of the form: Doug: X is bad, and could theoretically lead to end-user confusion in one particular obscure replay scenario, given a carefully chosen set of assumptions about MUA user interface design. World: Yes, X is bad, but it's out of scope for the DKIM protocol, as it's nothing to do with DKIM, rather it's a violation of 5322. World: Spam filters and MTAs should certainly consider it, though. World: Heck, DKIM *implementations* probably should, even though it's not part of the DKIM protocol - other than DKIM applies to email, and data streams with X are not email. Doug: If it's not in the DKIM protocol, then we are telling the entire world that they MUST NOT pay attention to X anywhere in their mail handling process... World: Uhm... what? No, we're not. That's just rid Doug: and that makes DKIM worthless! World: Uhm... what? No, that's not what we said. Repeat, ad- nauseam and beyond. Steve and Dave, Allow me to bring up a few new (albeit related) issues then. ADSP (RFC5617) depends upon DKIM's output. ADSP failed to consider a pre-pended header threat. When present, this unchecked threat means the Author Address is undefined. Those trusting ADSP results are placed at risk due to a lack of assurance pre-pended header fields were excluded. I think this is just a restatement of your previous concern, rather than a new issue. It seems out of scope for this thread, though, as this thread is discussing DKIM, while you're talking about an ADSP issue. Perhaps bringing it up in it's own thread (with ADSP in the subject line) would let people who are interested in the ADSP specific aspects pay attention to them. Message Header Field for Indicating Message Authentication Status (RFC5451) also depends upon DKIM's output. This specification also failed to consider a pre-pended header threat. When present, this specification lacks signaling to indicate whether signed singleton header field replicates were excluded and of course the header.from is undefined. Those trusting an Authentication-Results header field are placed at risk due to the lack of assurances that pre-pended header fields were excluded. This is just a restatement of your previous concern, it is not a new issue. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
