Re: [ietf-dkim] EAI and 8bit downgrades
Jiankang Yao: Is there any RFC which deals with EAI DKIM ? how to deal with EAI message in the DKIM? Do we have a decision about it? According to RFC 6530, in-transit downgrading of messages (described in detail in RFC 5504) is eliminated from EAI. Downgrading to an ASCII-only form may occur before or during the initial message submission, or after the delivery to the final delivery MTA. Thus, instead of being downgraded in-transit, mail is returned as undeliverable. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
Rolf E. Sonneveld: On 06/20/2013 03:05 AM, John R. Levine wrote: Now on the other hand, if an administrative domain wanted to go to the trouble to authenticate down to the user level, we didn't want to prevent that, either. The primary audience for DKIM includes regulated industries, after all. Seems to me that works fine as is. If a stock broker wants to set up its mail system to put an i= into DKIM that reliably identifies the person who sent the mail, they can do that. But unless I have external knowledge that they do that, and trust them to do it right, I can't depend on it, Why do you raise this concern for i= and not for d=? Simply looking at d= we can't differentiate between a Good Guy and a Bad Guy, until we have built some history/reputation for that particular d= domain. Why wouldn't the same logic hold for i=? Because d= specifies the name of the public key. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Weird i= in client mail
On 06/20/2013 03:05 AM, John R. Levine wrote: Seems to me that works fine as is. If a stock broker wants to set up its mail system to put an i= into DKIM that reliably identifies the person who sent the mail, they can do that. But unless I have external knowledge that they do that, and trust them to do it right, I can't depend on it, Rolf E. Sonneveld: Why do you raise this concern for i= and not for d=? Simply looking at d= we can't differentiate between a Good Guy and a Bad Guy, until we have built some history/reputation for that particular d= domain. Why wouldn't the same logic hold for i=? Wietse: Because d= specifies the name of the public key. Rolf E. Sonneveld: As there is only one private key associated with that public key, we may safely assume that the owner of that private key takes responsibility for any use of the i= within that d= domain. Or any other bits in the message header or body, for that matter. The point is that d= provides the authenticated channel between signer and verifier, while all the other bits are just riding along through that authenticated channel. This thread is really about different degrees of trust: trust in the authenticated channel, versus trust in the content that arrives through that channel. I may be willing to believe that the channel is authentic, while at the same time being sceptical about any claims that are made by its payload. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Debunking the d= domain and DNS myth (was: Removal of AUID)
John Levine: Another way is to have a dkim tag that specify the header that indicates the stream classification Many ways to kill the same bird. 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. To give a productive spin to the discussion: One little-known DKIM fact is that one does not need a different DNS record per d= domain. One strategically-chosen wild-card under _domainkey.example.com suffices (e.g. one per sub-organization). I agree that a different DNS record per d= domain can be a barrier for non-trivial organizations that have non-trivial latencies due to bureaucracy or even outsourcing, while bad guys in their small shops can crank out DNS records with negligible effort. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] wildcards, draft-ietf-dkim-rfc4871bis-03 submitted
John Levine: 2. Advice about wildcards in TXT records. Proposed change: Add a note in section 6.1.2 warning about the effect of wildcard TXT records on finding DKIM key records. Section 3.6.2.1 currently says: INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g., *.bar._domainkey.example.com) do not make sense in this context and should not be used. Note also that wildcards within domains (e.g., s._domainkey.*.example.com) are not supported by the DNS. That first sentence is just plain wrong. I have been using wildcard DNS records of exactly that form for months, and they work fine. I put a unique selector on each message, and when I get around to it will extract the DNS lookup info to figure out how many people are looking at my signatures. This may be morally reprehensible, but it does make sense. I suggest we delete the whole note. I suggest replacing this with the replacement 6.1.2 text proposed below, but I would not object to John's proposed changes either. So that's a +1 from me. Wietse Section 6.1.2 says: NOTE: The use of wildcard TXT records in the DNS will produce a response to a DKIM query that is unlikely to be valid DKIM key record. This problem applies to many other types of queries, and client software that processes DNS responses needs to take this problem into account. This is only true if the name of the record doesn't include _domainkey, so *._domainkey.example.com or *.foo._domainkey.example.com is OK, but *.example.com is not. So I suggest we rewrite it as: NOTE: Wildcard TXT records whose names are not in the _domainkey subdomain will generally produce a response to a DKIM query that is not a valid DKIM key record. This problem applies to many other types of queries, and client software that processes DNS responses needs to take this problem into account. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DOSETA and re-thinking the organization of the DKIM spec
John R. Levine: The new docs willuse the CORRECTED rfc4871bis text. Considering how far along we are with rfc4871bis, and keeping mind mind the objections from Jim and others, my inclination would be to finish and publish rfc4871bis as a standalone document, and after that do the DOSETA document that, as I understand it, pulls out components of DKIM and defines interfaces to them as a toolkit. There will be some overlap, but I don't see that as a huge problem. For the parts that say the same thing, our text editor cut and paste keys are ready and able to help. +1. I have no problems with the split, but if some people do, then let this not stand in the way of progress. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Japan has been set up
Ian Eiloart: Unless the intermediary co-operates by re-signing, mailing lists can break DKIM signatures. Since mailing lists generally use their own rfc5321 return paths, SPF failures should not result. Of course, a broken DKIM signature is equivalent to none at all. You should not reject or discard mail on this basis, but you do lose the ability to assign signer domain based reputation to the message. Unless the intermediary co-operates with SRS, or similar, *forwarding* can result in SPF failure. Since forwarders generally don't change the message content, DKIM signatures should remain intact. Please do not confuse mailing lists with email forwarding. The two are different things. It is not helpful to take an argument from one context and use that to prove a point in the other context. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] How MUAs render mail (was: Data integrity claims)
Mark Delany: My problem is that if some valuable domain like paypal sends me a bunch of bits that I or my MUA or my MTA ties to paypal.com then the end goal of DKIM is, IMO, that those bunch of bits I see are the ones that paypal sent. No more, no less. But the user does not see a bunch of bits. The user sees the combined result of software layers that render those bits. DKIM has no control over that rendering process. DKIM can only guarantee that what you RECEIVED is what I signed. To get what you SEE is what I signed semantics, one could do the following: a) Exchange all email as static image files. b) Make DKIM verifiers aware of all possible ways to exploit the message rendering process without breaking the DKIM signature. For example, prepend extra Subject: etc. header; add message header with JAVASCRIPT that overlays part of the message display; add other out-of-spec content, or corner-case within-spec content. c) Recommend that MUAs make it easy for users to recognize which parts of a message display are covered by whose (DKIM) signature. d) Go back to non-MIME ASCII-only email, use fixed-width fonts on 80-character displays and only mandatory, single-instance, non-folding headers. Of these, a) and d) solve the problem but are unlikely to happen, while b) and c) address the same problems in different places and will need to be revisited every time some new exploitable MUA feature is introduced. Option b) is called layering violation and c) is called kicking the can down the street. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] How MUAs render mail
Mark Delany: But the user does not see a bunch of bits. The user sees the combined result of software layers that render those bits. DKIM has no control over that rendering process. Really? Do you mean doesn't or shouldn't or can't? Does DKIM control text-to-voice conversion, or text-to-text language translation? These are just two ways of presenting email to a user that I could come up with. Obviously these two are among the more lossy transformations. But even text-to-screen conversion, without language translation, can produce different results with different MUAs as discussed at the beginning of this family of ietf-dkim threads. Apropos layering violations: are we saying that having a UA inject message 'A' via a DKIM layer into the mail stream, and then having some random/malicious goop cause message 'B' to pop out of the DKIM rabbit hole at the other end is less of a layer violation than ensuring that message 'A' comes out that rabbit hole? Bad guys don't have to play by the rules. For example, message A is sent by the signer, and comes out of the verifier as A++. The ++ stands for extra content that does not break the DKIM signature, but that changes the way the message content is presented to the user. This is one of the problems that this family of ietf-dkim threads is concerned with. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
MH Michael Hammer (5304): -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Friday, October 15, 2010 11:59 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Well a broken signature is morally equivalent to unsigned so Im not sure of the potential harm... And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I'm sure this was discussed before, but perhaps a refresher helps. How would the DKIM validator know the difference between: A: The message had a valid signature, but it was broken after signing. B: The message is a forgery with a bogus signature. If the DKIM validator cannot make that distinction, then the bad guys will do B and the validator will treat it as A. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Charles Lindsey: On Fri, 08 Oct 2010 18:25:40 +0100, Wietse Venema wie...@porcupine.org wrote: If I understand things correctly, the solution is already available in DKIM today. It involves signer configuration (sign for N+1 instances of each header that is covered by the signature) and requires no change in protocol or semantics. It merely hardens the DKIM signature and I see nothing wrong with doing so. If I am mistaken then please correct me. You are indeed mistaken. All you have ensured is that any message signed (say by ebay) is proof against reply attacks that add additional headers. But the scam we are considering does not involve replay attacks at all. It involves a message created and signed by the scammer using his own key. Please read my entire response carefully before responding. The above detects the case where a bad guy adds a forged header to a DKIM-signed message, in the hope that naive mail programs will render their forged header with an indication that THE GOOD GUY'S DKIM SIGNATURE VERIFIED. When the bad guy sends mail with (multiple) forged headers, the best they can get is that naive mail programs render their forged header with an indication that THE BAD GUY'S DKIM SIGNATURE VERIFIED. Sending forged headers with bad guy's DKIM signatures is not an interesting attack on DKIM. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Charles Lindsey: When the bad guy sends mail with (multiple) forged headers, the best they can get is that naive mail programs render their forged header with an indication that THE BAD GUY'S DKIM SIGNATURE VERIFIED. Sending forged headers with bad guy's DKIM signatures is not an interesting attack on DKIM. On the contrary, it is an exceedingly interesting attack. If you believe that sending mail with a valid bad guy signature is an interesting attack on DKIM, then that implies that you're willing to believe mail that is signed by arbitrary strangers. That is a problem that DKIM is not designed to solve. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John R. Levine: a) Author creates a 100% compliant message b) Signer signs 100% compliant message c) Bad guy adds an extra header, making it non-compliant, and sends it to someone ... Mike, I only have vague recollection of the h= trick anymore... You list all the headers you sign in h= list, and you can include headers that don't exist, which means that they can't exist when verified either. So for a header that occurs N times, you can list it N+1 times in h= to ensure that more aren't added. The original motivation was usually N=0 to avoid games played by adding MIME headers to messages that don't have them, but it's generally applicable. With this signer-side configuration solution, the verifier can detect attempts to spoof any header that was covered by the DKIM signature (spoof as in add a forged header, and hope that naive programs will use the forged header instead of the authentic one). So the solution is already available in DKIM. We just need to use the solution, and make it part of routine DKIM tests. Having the signer put the extra junk in h= should make existing verifiers do the right thing, although I doubt the bit of verification code that checks for the non-existence of the N+1st header for N0 is well tested in DKIM implementations. To address this, make this solution part of routine DKIM test suites. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Dave CROCKER: On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? I'm a bit confused. We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? If I understand things correctly, the solution is already available in DKIM today. It involves signer configuration (sign for N+1 instances of each header that is covered by the signature) and requires no change in protocol or semantics. It merely hardens the DKIM signature and I see nothing wrong with doing so. If I am mistaken then please correct me. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
If I understand things correctly, the solution is already available in DKIM today. It involves signer configuration (sign for N+1 instances of each header that is covered by the signature) and requires no change in protocol or semantics. It merely hardens the DKIM signature and I see nothing wrong with doing so. If I am mistaken then please correct me. It depends on the Application implementation of DKIM. What I describe would be a best practice application of DKIM mechanisms that already exist. Mail is signed as if there are N+1 instances of each header that is covered by the DKIM signature. The verifier will then fail if any such header is added after-the-fact. With this, there is no need to rely on enforcement mechanisms outside DKIM, such as the correct implementation of RFC 5322. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Wietse: What I describe would be a best practice application of DKIM mechanisms that already exist. Mail is signed as if there are N+1 instances of each header that is covered by the DKIM signature. The verifier will then fail if any such header is added after-the-fact. With this, there is no need to rely on enforcement mechanisms outside DKIM, such as the correct implementation of RFC 5322. Murray S. Kucherawy: I would suggest constraining that to include only those fields that are 0-or-1 in RFC5322 Section 3.6. For example, doing this with Received: is begging for signature invalidation on otherwise unaltered messages. I see your point, but there are more sensitive headers than the 0-or-1 headers in RFC 5322 (IIRC, the N+1 signing method was introduced to protect MIME headers). I suppose that the guidelines for best practice application of DKIM could recommend what headers to sign with the N+1 signing method. These guidelines can be updated as RFC 5322 evolves, and as standards that extend RFC 5322 introduce new sensitive headers. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Mark Delany: That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. Agreed. Though frankly I couldn't care less about signers. It's always the verifier that really counts. I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. +1. This makes more sense to me than trying to enumerate all the possible effects of malformed messages on naive programs. An explicit example may help to motivate the reader (Invalid messages must never verify; for example messages with multiple Subject:, From: or To: header fields). Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Discussion lists and broadcast lists are not the same thing
Alessandro Vesely: On 23/Sep/10 21:16, John R. Levine wrote: All of this emphasis on complex designs for MLMs strikes me as a waste of time, since it's a tiny corner of the mail space that has not historically been a vector for abuse, and shows no sign of becoming one. That's why my advice is that lists should sign their mail, which is easy and at worst harmless, and we're done. According to Murray's definition, MLMs include ESPs and email marketers, which originate a volume of traffic and have historically been a vector for abuse. Indeed, except for subscription mechanisms and deployed software, most of the problems are similar. It may be productive if we distinguish between two-way discussion lists where participants send mail to the list, and one-way broadcast lists where only the owner (or their agent) sends mail to the list. The difference between these is to be large enough that the concepts do not generalize that well. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
Scott Kitterman: On Wednesday, September 01, 2010 05:18:02 am John Levine wrote: ANNEX A - MUA Considerations Is a draft about mailing lists the right place to make recommendations to MUA developers? Seems like those should probably be in a separate document. No, but the entire document is riddled with advice that has no basis in experience and is unlikely ever to be implemented. We have a serious problem that people in this group have deeply incompatible ideas of what DKIM does. A lot of the arguments seem to be from people who believe that a DKIM signature can or should identify the individual author of a message, and that subscribers to mailing lists need assurances about the identity of list authors beyond the minimal level that has been adequate for the past twenty years. I have trouble understanding how anyone who is familiar with DKIM or with the operation of mailing lists could hold these positions, but it is quite obvious that some do. At this point, unless we can cut back the MLM document to stick to items that we have consensus about, e.g., that it is typical for signatures applied to incoming mail not to verify after a message passes through an MLM, and that it would be nice if a list or its MTA signed its outgoing mail, I don't think we will produce anything that is useful to anyone. If that's all we can say, I'd say don't bother. I don't see much value in the DKIM working group saying it thinks mail should be signed by DKIM. If we want to increase adoption of DKIM today, then I think there is value in a document that explains in plain words what DKIM actually does, in terms of what mailing lists actually do, and in terms of how MUAs actually work, common traps and pitfalls included. If we want to increase adoption of DKIM in some distant future, then we would need to speculate about what that future would look like, and that is not useful. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations
Hector Santos: IMO, it is these statements that continues to raise confusion and raise the barrier of industry wide adoption that includes the general population of MTA developers and operators from tiny to small to even large. As a part-time MTA developer I am not confused. The DKIM signature provides a simple piece of trace information (I handled this mail) that is cryptographically bound to some header and body content. The receiver can use this trace information for any purpose that she deems suitable. What seems to confuse some people is that the using part is entirely decoupled from the signing part, and that the signer has no control over what use is made. In my view, this decoupling is beneficial (DKIM as an enabler). For others, this open-ended design is a shortcoming (batteries required). Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Alternative MAiling List Approach
Should the MLM draft suggest From: replacement and addition of Reply- To: as a specific example of DKIM-friendly MLM behavior? No. DKIM doesn't really say much about either the From: address or the Reply-To: address, so such a suggestion for DKIM-friendly behaviour would be nonsensical. It might be a reasonable suggestion for the benefit of other protocols, but that's a different question. Is it not an ADSP issue though? Covering ADSP issues is (at least implicitly) in scope for this document. It may well be an ADSP issue - I've not looked in detail at the proposal - and it may be in scope for this document. (I suspect it's also a bad idea, but that's a separate discussion). It's definitely not a DKIM issue, though, and any labeling of a non-DKIM issue as DKIM-friendly would be misleading. IIRC we used to refer to the DKIM base signing spec and ADSP (and all the names it previously had, most of which I've fortunately forgotten) as both being part of DKIM. It seems a bit odd to me to refer to issues with specs produced by the DKIM working group as non-DKIM. -1. ADSP is fundamentally broken (not as badly as its predecessors) but DKIM is not. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Collecting re-chartering questions
John Levine: YES to 1, 7, 8. NO to everything else. (I.e., do find out what people are doing, do not invent new unlikely to be used mechanisms. Not opposed to 9, but seems contingent on 7 and 8 happening first.) +1. No new features before we have real-world experience. Wietse R's, John The list, as I've been able to distill it out of the lengthy discussions: 1. Advance DKIM base to Draft Standard 2. 3rd-party authorization label: https://datatracker.ietf.org/doc/draft-otis-dkim-tpa-label/ If you have not read this draft, please do; we'd like to get a good sense of whether to work on this. 3. Other 3rd-party signing issues (New protocol? Info doc?) 4. Mailing list cohabitation (dkim=except-mlist) 5. Other mailing list issues (info doc) 6. Specifying ADSP/forwarder guidelines for re-signing (is this different from mailing list issues?) 7. Collect data on deployment and effectiveness of DKIM base 8. Collect data on deployment and effectiveness of ADSP, and consider future of ADSP 9. Update overview and deployment/operations documents (info), as new data are collected. 10. Go dormant for a while, and revisit these questions in 8 to 12 months. ___ 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] Resigner Support of RFC 5617 (ADSP)
Michael Deutschmann: If this is indeed the official semantics of the protocol, then I would petition to add a dkim=except-mlist policy. Which means I sign everything that leaves my bailiwick, but may post to signature-breaking MLs. Are you going to announce all your users mailing list subscriptions in the policy record? If you do, that could be a privacy problem. If you don't, then the spammer can add any mailing list header to the message, and they can drive their truck through this hole. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Modified Introduction text for rfc4871-errata
Dave CROCKER: Proposed text: tThis currently leaves signers and assessors with the potential for making different interpretations between the two identifiers and may lead to interoperability problems. A signer could intend one to be used for reputation, and have a non-reputation intent in setting the value in the other. However the assessor might choose the wrong value and produce an unintended (and inaccurate) reputation assessment./t tThis update resolves that confusion. It defines additional, semantic labels for the two values, clarifies their nature and specifies their relationship. More specifically, it clarifies that the identifier intended for reputation lookups (such as white lists) by the assessor is the value of the d= tag. However, this does not prohibit message filtering engines from using the i= tag, or any other information in the message header, for filtering decisions. /t tFor signers and assessors that have been using the i= tag for reputation assessment a software change to using the d= tag is intended. /t +0.99 This clarifies what is the primary identifier that signers intend to send to assessors. If it helps to avoid stepping on sensitive toes, you could drop the last sentence, but I can live with it. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type
Siegel, Ellen: Eliot Lear wrote: The basic question is simply this: is it sufficient to list the key algorithm in the header? I don't see a plausible attack, so I'm okay +1 +1 with that. But let's at least have the debate based on facts. yup. +1 +1 Enlightened by the facts, +1 Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
Charles Lindsey: On Mon, 01 Jun 2009 15:49:28 +0100, Barry Leiba barryle...@computer.org wrote: I think it's a terrible idea to (1) leave signatures in a message after you break them, (2) add A-R without removing any already there, or (3) add A-R without a signature covering it. And I, on the contrary, believe it is a terrible idea EVER to remove a signature or an A-R header. There is never anything to be gained by throwing away information that someone more perceptive than yourself might find useful. Except, of course, when the bad guys use this to have their bogus signatures and their bogus A-R headers laundered by naive signers. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type
Dave CROCKER: Let's make sure everyone is in synch about what is being proposed: The suggestion is to drop a tag from the *DNS record*, /not/ from the *DKIM-Signature* header field. What is the benefit of having the DNS record list possible algorithms? A protocol like this has specification language that says everyone MUST support algorithm P and MAY support other algorithms. When the data arrive, they contain an indication of what algorithm has been used for this data. The MUST ensure basic interoperability. The MAY permits extensibility, based on mutual agreement. Requirements for supported algorithms can be extended by enhanced specifications MUST support algorithms P, Q and R. It does not really matter how many algorithms are referenced in the specification or how many might be in the future. The list is in the specification. And the arriving data declare which algorithm has been used this time. But what utility is there in having a signer list in an external record the algorithms they might choose to use? Absent this justification, there is not when for needing the feature. As I recall, the argument in favor of this tag in the DNS was a security concern that a message might arrive with an unauthorized algorithm. For myself, I was never quite clear what actual threat this represented, in terms of feasibility, likelihood or severity. Reasons to drop this feature from the DNS record: 1) It assumes that the domain owner is giving the private key to rogue signers that are willing to use unauthorized algorithms. 2) It requests that receivers ignore signatures from rogue signers when they use these unauthorized algorithms. 3) It won't stop rogue signers from sending mail that is signed with an unauthorized algorithm anyway. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= summary, as I see it
J.D. Falk: J.D. Falk wrote: MailMan is covered, though [ . . . ] (This message will be signed, too, with a different key on the same box.) Even better! The MIPAssoc server (also running MailMan) swapped my signature for Authentication-Results, and signed the new message. DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mipassoc.org; s=k1; t=1243013748; bh=KKzdl+Xw6IloZrUtOCIjcoI2bG8=; h=Message-ID:Date: From:MIME-Version:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=If3rAwfKN03nqJhjL EqKR6+0izu3ujK8ak0Oa4AMAuTwZtofkhfGqH6V11/OmvVIPclZ45L0zTsbmYT8XoXN 5c66LqkE9t/leS246vbssPyoNF3SBhrhFmhuSWno5S5YGLFb3bYto06u8dRLhmakafg 1MvoT6tUnSj5aHo+uCOI= Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n4MHZLXK017726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ietf-dkim@mipassoc.org; Fri, 22 May 2009 10:35:27 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header...@cybernothing.org I love it when FUD is so easily overridden by operational reality. +1 on the motion to kill and six-feet-under the l= option. As for evangelizing, perhaps the DKIM website can put up (pointers to) HOWTO guidance for stripping DKIM headers and re-signing submissions as in the above example. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] let's screw up a good thing
Michael Thomas: I just don't get it. It seems to me that people who are advocating changing the spec are doing it in a complete vacuum of the wide deployment out there. Is DKIM broken? Manifestly not even a little which is quite remarkable. Every single suggestion has been debated in the past, and every suggestion if adopted would cause a wave of incompatibility problems. Any supposed simplification of the spec would be radically outweighed by dealing with the complexity of those incompatibilities. So simplification is not a valid argument. So what is the real motivation here? Is the real intent to cripple further deployment? Or maybe people don't have enough to do with their day jobs? Or maybe the thrill of making dev managers lives suck is just irresistible? If not, what? This is not a discussion. This is an accusation. I will not play your game, and I can only hope that others won't either. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
Hector Santos: Wietse Venema wrote: signed and invalid unsigned This distinction helps the bad guys/gals, and hurts the good guys/gals. Thats an opinion and not one based on any engineering proof. The fact is, the value of DKIM will be realized on anonymous transactions when you don't know who is GOOD or BAD. When reputation is know, DKIM has less value. Think Experts Systems, Diagnostic Systems, Neuron and Fuzzy Boolean logic. By eliminating the all important critical mal-function state, the potential to learn is lost. The potential to add tolerance levels is lost. i.e, anyone with perpetual failure can eventfully be dealt with. And by failure, that means any condition that is not expected, whether its the l= or x= detected problem, or just plain hashing failure. In lieu of a standard DOMAIN Policy protocol as a major part of DKIM, it is far worst to ignore failure and promote it to unsigned state than to keep this state and pass it on to the next level - whatever that is. To me, this is the REAL BIS material that should be reevaluated, because to me, that is one of the barriers to adoption. I rest my case. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Whither 4871bis?
John Levine: with some editorial changes I guess. I've not seen anyone suggest that we add features or remove a raft of features or make other substantial changes. I'm with Steve, I'd like to deprecate the useless stuff. I too am in favor of less complexity. We could start by keeping only the attributes that must always be sent. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP Informative Note on parent domain signing
Jim Fenton: Barry Leiba wrote: This discussion seems to have settled down, but I don't see a clear consensus on it. Let's take a little poll, then, on this thread. No further discussion, for now, just the poll, and please don't assume that silence means anything. Post to this thread, one of the following: Include the informative note. Do not include the informative note. I don't care [or I have no opinion] either way. Just to clarify the version of the Informative Note that I believe is in play at this point, it should be the one that's based on Ellen Siegel's wording: Informative Note: DKIM signatures by parent domains as described in section 3.8 of [RFC4871] (in which a signer uses i= to assert that it is signing for a subdomain) do not satisfy the requirements for an Author Domain Signature as defined above. I don't care Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Consensus point on ADSP
Charles Lindsey: From: some...@foo.exampleFrom:some...@foo.example Valid signature from foo.example Absent/broken signature from foo.example ACCEPT DISCARD Right. From some...@bar.example From some...@bar.example Valid signature from foo.example Absent/broken signature from foo.example ??? ADSP is about first-party signatures. The above are not, thus the discard rule applies. See draft section 2.7. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] what is a standard, was errata revision: Assessor
Murray S. Kucherawy: On Thu, 26 Mar 2009, Hector Santos wrote: And as long as this mindset persist, you are going to get the funny looks from many disciplines in this market - mainly SMTP vendors! I represent an SMTP vendor, and I'm not sending funny looks. I'm pleased with these developments, and I concur with the stated guidance. I'm kind-of a vendor, but I would not spend energy debating positions that have only one supporter. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Postfix: change of Content-Transfer-Encoding breaks DKIM signature / RFC recommendation
Florian Sager: According to the mails below the RFC compliant change of content encoding in MTA-forwarding may break signatures that follow the RFC 4871 recommendation to include header Content-Transfer-Encoding in the signature. This header should be removed from section 5.5. Recommended Signature Content (The following header fields SHOULD be included in the signature ...). Unfortunately, this does not solve the problem. The 8bit-MIME to 7bit conversion as required(*) in RFC 1652 replaces the entire message body, and therefore it invalidates DKIM signatures even when the Content-Transfer-Encoding header is not signed. Just like other MTAs that implement 8bit-MIME according to the rules, the Postfix SMTP client has an option to ignore the rules and send 8bit-MIME anyway. Wietse (*) Either convert the body, or return the message as undeliverable. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Postfix: change of Content-Transfer-Encoding breaks DKIM signature / RFC recommendation
Wietse: Unfortunately, this does not solve the problem. The 8bit-MIME to 7bit conversion as required(*) in RFC 1652 replaces the entire message body, and therefore it invalidates DKIM signatures even when the Content-Transfer-Encoding header is not signed. Just like other MTAs that implement 8bit-MIME according to the rules, the Postfix SMTP client has an option to ignore the rules and send 8bit-MIME anyway. (*) Either convert the body, or return the message as undeliverable. Florian Sager: Well, I thought the canonicalization would reduce the encoding problems but I didn't check this. I expect if a redesign of DKIM would take place an improved canonicalization method could solve this problem? DKIM does NOT replace the message body. It either signs messages, or it verifies DKIM signatures and if successful reports whose signature it found. The latter however remains a point of some controversy, so don't take my word for it. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] errata revision: opaque
John Levine: 7. RFC4871 Section 2.10 Agent or User Identifier (AUID) Old: A single, opaque value that identifies the agent or user on behalf of whom the SDID has taken responsibility. New: A single domain name that identifies the agent or user on behalf of whom the SDID has taken responsibility. For DKIM processing, the name has only basic domain name semantics; any possible owner-specific semantics is outside the scope of DKIM. While I'd think it would be dandy if the i= were a domain name, I suspect I'd be outvoted, so perhaps it would be better to say something like this: A string that identifies the agent or user on behalf of whom the SDID has taken responsibility. The string has the syntax of an e-mail address where the domain part is the same as the SDID or a subdomain of the SDID. For DKIM processing, the AUID has no semantics beyond validation that it complies with the syntactic rules; any possible owner-specific semantics is outside the scope of DKIM. +1 I wasn't aware of a proposal to change i= into domain form, but I must admit that could not attend the entire meeting over the phone. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Acronyms
Dave CROCKER: Is anyone /against/ using AUID? d/ Suresh Ramasubramanian wrote: On Thu, Mar 12, 2009 at 3:54 AM, Barry Leiba barryle...@computer.org wrote: Somewhat whimsically but wholly serious: Would simply changing the acronym to AUID (for Agent or User IDentifier) avoid mistaken connotations associated with User Agents (UAs)? WFM. +1 +1 Looks good to me. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the errata after the consensus call
John Levine: I'm not sure what my opinion is on that last point, but on the first point I think it's best to define an identifier that's specifically for ADSP's use, if we want that function. Some signers may give that tag the same value they give i=, and there's no harm done. Some signers may use a different value, which would demonstrate the wisdom of separating them. Seems like a reasonable way to avoid the i= fight. If there's interest, I can whip up a new ADSP draft with an r= tag. I am not sure how adding an r= tag would help deciding whether a specific d= domain has made a first-party signature on behalf of the rfc822.from. Another way to avoid the i= fight is to design it out of ADSP (leaving it in DKIM, if it can't be eliminated there). ADSP is looked up for mail without a first-party DKIM signature. In an ADSP without i=, the ingredients for the first-party signature decision are: 1) DKIM signature check: Is the DKIM signature valid per DKIM rules (this may or may not involve i=, but that is outside ADSP's scope). 2) First party check: Do rfc822.from and d= have the proper relationship. This check is ADSP-specific. If these checks fail, look up the ADSP policy for rfc822.from and make a ruling. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] a protocol needs a payload
Eliot Lear: The question one has to ask is broader than inputs and outputs. Are each of the protocol elements described in the specification clear enough to be understood as to their meaning? If they are not then that is what needs to be clarified. Regardless, this debate about functional programming (which is really what this boils down to) is pointless, and you are ossifying a structure around a model that you needn't do. As we have seen many times at the IETF, successful specifications are those in which the model can easily evolve over time based on circumstances. This is precisely the case with DKIM, where the AD's and the IESG's intent was to walk slowly before we run. The DKIM specification reflects that intent. Your errata reflect a different intent. If intelligent people cannot agree on what is the result of a protocol, then there is a problem that needs to be fixed. The proposed errata address the problem. The alternative does not. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Consensus call on d=/i= clarification
Stephen Farrell: (a) The erratum I-D [1] is ready to go. Process it. Motivation: Adding tweaks to a confusing document does not remove the confusion (you can consider this my variant of Brooks's law). Confusion is removed by stating clear terms up-front, and by casting the discussion into those terms. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Requesting working group LastCall on: draft-ietf-dkim-rfc4871-errata-02
Siegel, Ellen: I for one would prefer a straight up +1/-1 vote on the errata draft as it stands. +1 I do agree that it would be a Good Thing to roll this and all the other errata into a -bis spec draft, but think that it would be better to nail down what we have as errata first given the time required to revise the entire draft. +1. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Let's avoid opaque
Jim Fenton: I'd like to see if there is consensus for my proposal to remove the term before suggesting specific language. I suggest: you propose a concrete replacement, and if it is better, then we adopt it. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Possible exploit of DKIM
Thiyaga: Hi, We recently decided to implement DKIM in our organization. While reading through the RFC, I found a possible case, where the authentication is lost. (Sorry if it is already discussed and a known issue) Scenario: Let's assume a spammer wants to spam email accounts on domain X.com and the spammer uses a domain Y.com. Both the domains have implemented DKIM. This looks like a standard replay attack. Such technique can't be used to send SPAM on behalf of domains that don't sign SPAM (e.g., porcupine.org). If a domain is willing to sign SPAM, then they deserve that all their messages are handled with great prejudice. It is possible to take DKIM-signed messages with signature and all, and to append SPAM at the bottom, but that is not a very effective way to reach many eyeballs. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Progressing ADSP (Was: Re: New Version Notification for draft-ietf-dkim-ssp-06 (fwd))
J D Falk: On 20/09/2008 08:06, Dave CROCKER [EMAIL PROTECTED] wrote: Stephen Farrell wrote: It might be no harm if folks who do think ADSP should go ahead would respond to this saying so. +1 +1 +1. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue 1576: Revise wildcard discussion
Frank Ellermann: The version in ssp-04 IMO misses the following wildcard TXT points: (1) There is no explicitly specified way to identify an ADSP record, when it comes as one of several TXT records in a q=txt reply. In the terminology of an IAB draft ADSP defines no TXT subtype. Eliot Lear: The authors have chosen the DKIM style of using _adsp.domain, which effectively provides for subtyping. Do you not believe that is sufficient? I'll argue that the use of _adsp is actually better in that you don't have to parse through a bunch of crap to get to the appropriate record (normally). You still need the code checks, of course. This _adsp subtyping does not work with wildcards, unless one has a DNS server implementation that supports wildcards in the middle such as _adsp.domainkey.*.example.com. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE 1573: Modify ADSP Lookup Procedure
Note: The results from DNS queries that are intended to validate a domain name unavoidably approximate the set of Author Domains that can appear in legitimate email. ... I'd like to suggest that we use a different word than approximate in the above discussion and in the Levine draft. ... I suppose that overapproximate would be OK within the constraints of 2821. ... I can definitely live with approximate.nbsp; I don't think overapproximate is even a word, or if it is, it may mean something else so let's avoid that one. This (over)approximation issue is confusing, and it can be eliminated with a more precise definition of what domains are in scope for ADSP. After writing the text that evolved into what's in the Levine draft, my thoughts have evolved towards the following: ADSP as defined in [ADSP] is bound to DNS. For this reason, ADSP is applicable only to Author Domains with explicit ADSP DNS records. The handling of Author Domains without explicit ADSP DNS records is outside the scope of [ADSP]. However, attackers may use out-of-scope Author Domains in an attempt to sidestep an organization's explicit ADSP policy statements that some or all email is signed. For this reason receivers MUST handle out-of-scope Author Domains appropriately. The ADSP scope algorithm then simplifies into: - Receivers MUST look up the DNS MX record for the Author Domain. If the lookup completes with error code 3 (NXDOMAIN) the Author Domain does not exist in DNS, and therefore it is not possible to publish an ADSP record for the Author Domain. Receivers MUST treat such out-of-scope Author Domains as an error. - Otherwise, the Author Domain exists in DNS, but the organization publishes no ADSP record for the domain. Receivers SHOULD resolve the domain as required by [SMTP]. If the domain does not resolve, receivers SHOULD treat such out-of-scope Author Domains as an error. - Otherwise, receivers MAY treat such out-of-scope Author Domains as if the organization had published an explicit ADSP policy statement of unknown. So the algorithm simplifies into: MUST do NXDOMAIN test for MX lookup, SHOULD resolve the domain per [SMTP]. Whether it's SHOULD or MAY (or even not at all) depends on a trade-off between the predictability of receiver behavior against typical overhead and the potential for abuse in packet multiplication attacks. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Consensus check: Domain Existence Check
modify (clean up the definition of what is out-of-scope, clean up the handling of out-of-scope domains). Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-levine-dkim-adsp-00
Arvel Hathcock: What do you feel are the technical deficiencies of draft-levine-dkim-adsp? The biggest problem of course is that it's not a working group document. If we're to start working now on other documents then Doug Otis is ahead of you guys in line since he's had a replacement offering for some time. Let's not start down that road. Let's just get on with having the chairs conduct a straw-poll. The question is pathetically simple: Should the next draft of the working group document retain the NXDOMAIN check or not? Yes or no. This is really easy folks. If there is insufficient consensus either way then we can either give up or work toward some compromise language. The least ambiguous ways to validate an author domain are a) get an NXDOMAIN result for the author domain; b) talk to an authoritative SMTP server for the author domain, which is obviously not practical. DNS lookup per RFC 2821 section 5 provides only an approximation of what author domains are valid: not every A//whatever record corresponds to a valid origin of email. So we might just as well keep it simple and settle for the existing NXDOMAIN check. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
MH Michael Hammer (5304): Focusing on subdomains, I believe it may be useful for both senders and checking receivers if a domain were to be able to assert whether it's policy applies to all of it's subdomains. Given that we don't know how receivers or reputation services might utilize such an assertion, I would avoid must or should for a check at this stage. How would a receiver discover the top-level domain given example.com, example.ac.uk, example.org.au, etc.? Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] subdomain strawpoll
Delete. And bury six foot deep, so that it won't come out again. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
J D Falk: Wietse wrote: How would a receiver discover the top-level domain given example.com, example.ac.uk, example.org.au, etc.? The same way we do now: annoying, manually maintained case statements. And who will provide updates to all the ADSP verifiers in the field? Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
Jim Fenton: Dave Crocker wrote: J D Falk wrote: Wietse wrote: How would a receiver discover the top-level domain given example.com, example.ac.uk, example.org.au, etc.? The same way we do now: annoying, manually maintained case statements. This relies on a resource that is not specified in the document, is not publicly standardized, and changes. Not such a good thing. Exactly what terrible outcome does this produce if this is done wrong? It's unlikely that com, ac.uk, or org.au are going to publish ADSP records. So there is an unnecessary query to the parent, which is probably cached anyway (15 minutes for com, 1 day for ac.uk). Jim, You deleted the context of the original question: a mechanism that allows organizations to advertise a policy in one place that applies to their entire DNS tree. In the absence of a solid algorithm that determines the top of an arbitrary organization's DNS tree, verifiers will have to walk up the entire DNS tree from the bottom. Thus, ADSP becomes a tool thay can be mis-used for trivial amplification attacks by sending rfc2822.from addresses with many domain levels. That is not a good thing for a protocol that attempts to improve security. The prime directive should be do no harm. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Section 3.1 - ASP Usage
SM: At 16:27 29-04-2008, Douglas Otis wrote: Do you think there should be a statement indicating the ADSP lookup procedure should not be done when there is a valid Author Domain signature? Perhaps the receiving domain only validates DKIM signatures when ADSP indicates Discardable. : ) My question is about the implementation of ssp-03. The example which was tested is an odd case as we have a dkim=pass and dkim-asp=fail. Section 3.1 of the draft says: If a message has a Valid Signature from an Author Domain, ASP provides no benefit relative to that domain since the message is already known to be compliant with any possible ASP for that domain. I read that as meaning that as the ASP (ADSP) lookup is not done then. I'm not saying that it should not be done. :-) I wrote the predecessor of that text. The reader has to understand that ADSP targets email without valid author domain signature. If a message has a valid author domain signature, then the signature speaks for itself, and ADSP is not needed. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
Dave Crocker: Arvel Hathcock wrote: I propose that the side advocating removal of the NXDOMAIN check agree to language which makes this step AT LEAST a SHOULD and preferably a MUST. Having the ADSP specification include normative text that calls for validating the From field domain name does two things: 1. Couples an entirely separate and more generally useful mechanism (checking domain name validity) to one that is considerably more limited (ADSP). 2. Modifies SMTP. (Yes, really.) Having non-normative text that describes it serves to promote the idea but not couple it with the fate of ADSP. Instead of discussing how many angels fit on a pinhead, I suggest that we do something sensible, like: ADSP is bound to DNS, and therefore it's defined only for author domains that exist in DNS. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Are subdomains like parent domains?
John Levine: I think I'm not the only one making assumptions here. Of course not. I'm honestly trying to figure out whether any mail systems treat mail from sub.foo.com as being from foo.com when they make decisions about sorting, filtering, and so forth. That's why I'd really appreciate some actual examples if there are any. I'm not trying to be confrontational here, I'm trying to gather data. As far as I can tell, nobody does, but the whole issue of the tree walk is predicated on this assumption. If the assumption is indeed untrue, the treewalk (in any of its varieties) serves no purpose and we can just get rid of it. We're trying to solve two different problems at the same time. Question 1: What do real DNS deployments look like? Seems no-one can answer that here. Everyone is concerned that ADSP introduces unnecessary barriers for deployment, but discussions about random real or fictitious pain symptoms are not the best way to define a solution. This is an argument to avoid ugly ad-hoc hacks like the two-level DNS dance, because they lack a sound foundation. Question 2: What would the bad guys do to side-step DKIM/ADSP, for some particular set of ADSP implementation details? I can answer that with confidence. They will do everything that gets their email through the filters. Unlike ADSP implementors, spammers are not bound by the rules of the RFC. Our lack of imagination should not give us a false sense of security. This is an argument to have some safety net mechanism like the ugly two-level dance that automagically covers all nodes at the same DNS level; nailing non-existent domains at lower DNS levels is already trivial without ADSP. As fas a I'm concerned someone can toss the coin and be done with it. I'd rather have something that mostly works now, than something that will be perfect for one microsecond. No system can be perfect permanently with respect to constantly changing threats. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] protecting domains that don't exist
Wietse Venema wrote: Frank Ellermann: [EMAIL PROTECTED] wrote: Would it be better if error were a specifically defined result in addition to unknown / all / discardable? The fourth bullet in chapter 3.2 ASP results offers the domain does not exist after unknown/all/discardable. I-D.kucherawy-sender-auth-header chapter 2.4.2 ASP results lists this as nxdomain. IMHO good enough, or do you have something else in mind ? Let's s/ASP/ADSP/g + WGLC, s.v.p. Sounds reasonable. I expect many will implement NXDOMAIN as a fourth ADSP lookup result in some way or another. This explains more easily than my earlier claim (an NXDOMAIN result cannot correspond with one of unknown / all / discardable). Dave Crocker: Sorry for being confused, but I now can't tell whether the focus is on an NXDomain for the _adsp.domain string that is queried for ADSP, or the domain name to which it is associated. I am talking about DNS lookup #2 in ADSP: the author domain. _adsp.domainkey.example.com IN TXT (NXDOMAIN - unknown). example.com A IN (NXDOMAIN - nxdomain). By including nxdomain as a verifier result we can eliminate a confusion and frustration. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
a) DKIM is for declaring the presence of an accountable identity. If a signature is present, you know something. If it is absent, you know nothing extra. b) ADSP attempts to tell you something, in the absence of a signature. It does that by defining something else that must be present. If the ADSP record is present, you know something. If it is absent, you know nothing extra. c) Checking for the presence of [any DNS] record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. To clarify a perhaps overlooked point: the existence of [any DNS] record for the Originator domain does NOT imply that it is a valid email origin. If the record is absent, then we know nothing that the absence of the ADSP record for that domain didn't already tell us. Any suggestion to the contrary is probably a mistake. While there is nothing wrong with checking [any DNS] record, it's semantics have literally nothing (directly) to do with ADSP. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Wietse Venema wrote: a) DKIM is for declaring the presence of an accountable identity. If a signature is present, you know something. If it is absent, you know nothing extra. b) ADSP attempts to tell you something, in the absence of a signature. It does that by defining something else that must be present. If the ADSP record is present, you know something. If it is absent, you know nothing extra. c) Checking for the presence of [any DNS] record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. To clarify a perhaps overlooked point: the existence of [any DNS] record for the Originator domain does NOT imply that it is a valid email origin. If the record is absent, then we know nothing that the absence of the ADSP record for that domain didn't already tell us. Any suggestion to the contrary is probably a mistake. Jim Fenton: ADSP is doing the converse of that: it takes the non-existence of [any DNS] record for the Author Domain as an implication that it is NOT a valid email origin, or more accurately reports if that is the reason there isn't an ADSP record for that domain. The problem is that valid email origin is a subset of all the names that resolve in the DNS. In other words, there are false positives in the algorithm that continues when [any DNS] record lookup succeeds. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Practices protocol naming poll (Closing issue 1550)
Stephen Farrell: Poll ends: April 3rd AoE (*) Please mail the list with your preferences. Tick the box for any of the name options you like. You can pick more than one option. If you change the subject line or mess with the body of the mail, I may miss or miscount your opinion, so don't do that. [ ] ADSP - Administrative Domain Signing Practices (**) [X] ADSP - Author Domain Signing Practices [ ] ASP - Author Signing Practices [ ] FroDo - From Domain Signing Practices [ ] SPAD - Signing Practices of Author Domains [ ] SSP - Sender Signing Practices (*) AoE = Anywhere on Earth (http://wirelessman.org/aoe.html) a slightly silly, but I guess useful idea here. (**) The word Policy was used when this was suggested, but I think we do have consensus to prefer Practice instead, so I made that change. ___ 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] New Issue: Third parties in overview
Frank Ellermann: Dave Crocker wrote: third-party can be confusing. Later in the draft and after posting the issue I saw non-author. That's also fine, but the interesting case isn't an originating operator (that is still end-to-end), but signatures by mediators. And how would receivers tell the difference between these scenarios? My position is don't assign different semantics to scenarios that are indistinguishable to receivers. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue 1550 - the name of the document (remains open *briefly*); there's still,disagreement on Author
Michael Thomas: Dave Crocker wrote: Michael Thomas wrote: It doesn't take much of a logic chain: the label first was _policy. Then it was _ssp. Now it's _asp. Tomorrow it might be _frodo. Next day something else. Each time you change it, implementations break in a showstopper way. Your argument appears to be that people who implement Internet-Drafts should have sway over the ability to change those drafts. Hold sway != have a say. I think that people who have some skin in the game should be considered carefully. What I read here is dismissal (= hold sway). That argument is not without precedent, but it almost never is acceptable to the working group to let that narrow installed base dictate working group choices. Dave. My irritation here is that it doesn't seem to even be on anybody's radar that you are breaking implementations utterly and completely. Doing that is devaluing running code which last time I checked counts for something. I'd really like to deploy something for the reflector, but this silly last minute name changing makes that all pointless. Gentlemen, let's focus on getting it right for future deployment, and not on maintaining continuity with temporary experiments. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue 1550 - the name of the document (remains open *briefly*); there's still,disagreement on Author
Eric Allman: Since we decided to change SSP to ASP to be more precise (thereby breaking the existing implementations out there, which Dave seems to think are irrelevant, Mike seems to think are critical, and I think are somewhere in between), I'm in favor of making one more change (my preference: ADSP), but then to freeze it, absolutely and completely. Dave seems to be forgetting that early implementations of drafts are a good way to get practical feedback into the process --- it's more than a gedanken experiment. Mike seems to forget that these /are/ drafts, and drafts do (and should) change. I can live with ADSP. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
Douglas Otis: The current assumption used when asserting DKIM policy is that this policy might apply across _all_ protocols used to carry messages that might contain DKIM signatures. Either DKIM policy records need to declare the scope of the protocols covered by the policy, or the label used to discover a policy should employ different labels. Add: Policy assertions for _SSP records are limited to messages exchanged by SMTP. When other protocols are used to receive messages, the appropriate policy should be applied upon receipt, and/or the protocol should be tracked within the message. One method for such tracking could be implemented using Authenticated-Results headers. Excuse my ignorance, but why limit DKIM (or SSP) to information that is delivered via SMTP? They can work with any transport that uses RFCx822 for content and that uses DNS for name resolution. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
Wietse Venema: Douglas Otis: The current assumption used when asserting DKIM policy is that this policy might apply across _all_ protocols used to carry messages that might contain DKIM signatures. Either DKIM policy records need to declare the scope of the protocols covered by the policy, or the label used to discover a policy should employ different labels. Add: Policy assertions for _SSP records are limited to messages exchanged by SMTP. When other protocols are used to receive messages, the appropriate policy should be applied upon receipt, and/or the protocol should be tracked within the message. One method for such tracking could be implemented using Authenticated-Results headers. Excuse my ignorance, but why limit DKIM (or SSP) to information that is delivered via SMTP? They can work with any transport that uses RFCx822 for content and that uses DNS for name resolution. -1 for the updated proposal. Cosmetic surgery on a dead horse won't bring it back to life. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: Rename SSP to ASP
Dave Crocker: The practices that SSP describe are specific to the RFC2822 From: header field, which defines the author of a message. It does not seek to describe practices of other agents in email handling. As such, the name of the specification should reflect its precise scope. The current name of Sender Signing Practices is imprecise and misleading. The name should be changed to Author Signing Practices (ASP). +1 Call it ASP. The use of author domain in the text will eliminate confusion about the meaning of the A. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE: Rename SSP to ASP
Hallam-Baker, Phillip: [ Charset ISO-8859-1 unsupported, converting... ] My problem here is that Phill Hallam-Baker is the Author of this email but verisign.com would be the signer. I would be somewhat nervous about making the assertion that a domain is the author of a message. That might be exploited for purposes of legal mumbo-jumbo. Perhaps, Domain Signing Practices? DKIM / DSP fit together well. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Unacceptable
Frank Ellermann: From my POV discardable is worse. Above all receivers have to follow 2821bis. SSP does not guarantee that discardable mails match what is specified in 2821bis section 6.2. One possible deployment of ASP would work like this: - Have the MTA/Verifier tag discardable mail with a hint to the recipient. - Leave the handling of this hint up to recipient preferences. This does not violate the prime directive of x281, nor does it force MTA operators to throw away mail, which may be forbidden. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: SSP-02: MX Record publishing mandate to reduce DNS overhead for SSP Discovery and to detect fraudulent messages
Douglas Otis: To better ensure the minimum number of DNS transactions occur while processing DNS SSP and key TXT records, especially for domains that do not implement email, the SSP draft should mandate publishing MX records whenever an SSP record is also published. Since the SSP discovery process makes use of MX record queries to determine whether the domain exists, then when an SSP record is returned for a domain that has not published an MX record, this thereby signals that both email and DKIM are NOT used for email addresses at this domain. This strategy affords a better cache hit rate during the SSP discovery process, the detection of fraudulent uses of the domain, and a means to protect second level domains. -1. Per the draft, an NXDOMAIN reply for an Author domain lookup already terminates the SSP algorithm with failure. This is good enough. DKIM and SSP are not appropriate vehicles for making other records mandatory where now they are not. When the SSP record is returned without there also being an MX record at the Author Domain, the signature SHOULD BE considered fraudulent without further DNS transactions being attempted. _1. I oppose the re-introduction of suspicious, fraudulent, etc. Those are overly-specific interpretations of failures that will more often than not have non-malicious causes. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Michael Thomas: Eliot Lear wrote: Wietse Venema wrote: You do what you want to do. I would hope that receivers don't discard mail simply because the domain owner says so. Instead, I would hope that their hint goes into a weighting process together with other indicators. Ain't nothing wrong with this approach. If someone wants to zero out the other indicators, it's up to them. I for one will want to consider reputation of the sender along with SSP results (to say the very least). The rest of this thread seems to me moot based on the current direction of SSP-02. Well I think that's perfectly prudent too. What I was reacting to is this notion that I have to know the domain in question to assign those weights -- whatever it means to know. The ag example is a good one where I'm nearly certain that I don't know them = layer 7, but I'm happy having them give me SSP advice for those layers to act on. I don't need to have some prior relationship with them to make that negative assertion be useful. I admit, the need to know is mainly for whitelisting, which I view as the primary purpose of DKIM and what's built on top of it. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
MH Michael Hammer (5304): If a domain chooses to sign DKIM with respect to a From field email address that purports to be from that domain and that domain has the ability to make an assertion (of any sort) through SSP with regard to it's practices: Is the potential benefit afforded a receiver by checking that SSP assertion AND taking whatever (unspecified) action worth the effort of doing so? If receivers are likely to have little or no benefit/interest in checking SSP then the rest of the discussion is moot. In other words, is the juice worth the squeeze? Spammers can use DKIM and SSP too. Therefore and the juice is not worth the squeeze unless the receiver actually knows the domain. Perfect DKIM+SSP by a total stranger is relatively meaningless. But we've already visted that station many times in the past. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Steve Atkins: My original observation was that discardable was a reasonable term for mail for which the sender prefer the recipient not deliver a small fraction of legitimate email and a small fraction of non-legitimate email rather than deliver either. There was an assertion made that the small fraction of non- legitimate email here was actually 100% of the non-legitimate email. That assertion was shown to be false, so we can ignore that digression and return to where I came in, which was: It's an assertion that the sender would prefer that the recipient not deliver some small fraction of legitimate email as well as some small fraction of illegitimate email, rather than delivering those small fractions of legitimate and illegitimate email. In the senders opinion, it is more important that mail claiming to be from them not be delivered than for it to be delivered. The english meaning of discardable matches the semantics pretty well. If we want implementors to easily understand and deploy the specification, and more importantly the limits of them doing so, thats fairly important. +1. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
MH Michael Hammer (5304): Is the potential benefit afforded a receiver by checking that SSP assertion AND taking whatever (unspecified) action worth the effort of doing so? If receivers are likely to have little or no benefit/interest in checking SSP then the rest of the discussion is moot. In other words, is the juice worth the squeeze? Wietse: Spammers can use DKIM and SSP too. Therefore [..] the juice is not worth the squeeze unless the receiver actually knows the domain. Perfect DKIM+SSP by a total stranger is relatively meaningless. MH Michael Hammer: I'm asking in terms of the overall implementation. In a world where all domains are strangers the juice is definately not worth the squeeze. That is the chicken and egg of kickstarting adoption. The far majority of email is from strangers. Specifically, there is an awful lot of email with me as recipient from apparent senders that I have no relationship with. I have no reason to believe that my experience differs radically from that of other people. Is the same true where half (or pick a percentage of your choice)the domains are strangers? At what point do the benefits of checking outweigh the costs of checking? Honestly, I know of no reasons why spammers would start to send less email. There is a lot of spam out there that has nothing to do with domain spoofing and everything with gullible greedy recipients. So if it isn't 3PS (01) and it isn't ASP (02) then what is it that is to be identified/protected by SSP? It's primarily about whitelisting what's known to be good. When I get mail that claims to be from a total stranger then it does not matter if it is 100% DKIM/SSP compliant. Is DKIM checking sufficient in itself without SSP? How might DKIM-SSP help receivers (the 3 aforementioned as well as others) leverage their evaluation of received email whether signed (valid or not) or unsigned? known to be good whitelisting can be done with DKIM-BASE alone. SSP etc. is about the ABSENCE of valid signatures, and can help to strengthen the known to be good whitelisting process. When I get mail that claims to be from a total stranger then it does not matter if it is 100% DKIM/SSP compliant. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Michael Thomas: Wietse Venema wrote: MH Michael Hammer (5304): Is DKIM checking sufficient in itself without SSP? How might DKIM-SSP help receivers (the 3 aforementioned as well as others) leverage their evaluation of received email whether signed (valid or not) or unsigned? known to be good whitelisting can be done with DKIM-BASE alone. SSP etc. is about the ABSENCE of valid signatures, and can help to strengthen the known to be good whitelisting process. You've said this several times, but I don't think that's the range of all possibilities. Ag.com is a pretty good example of somebody that I as a receiver don't know but if they're willing to say discard this if it's not signed, all other things being equal why wouldn't I? You do what you want to do. I would hope that receivers don't discard mail simply because the domain owner says so. Instead, I would hope that their hint goes into a weighting process together with other indicators. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: forgeries (Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt and ASP)
Hector Santos: Dave, Is it fair to conclude that you no longer feel it is necessary to do a Security Threat Analysis? Unfortunately, I know you are not going to respond, so I want to put in F.Y.I. Text is being drafted, but you will have to wait until it is ready. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] draft-ietf-dkim-ssp-02.txt and ASP
In my opinion, as one of the authors listed on the ASP draft, SSP-02 is close enough in spirit to ASP that I could live with either. The protocol is extensible. Let's gain experience with this basic protocol and let experience teach us where extensions will be useful. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: the more reliable signature fallacy
Frank Ellermann: John L wrote: This is the exact problem for PRA in the SIDF implementation. Quite right. What would be the point in inventing yet another authentication scheme that fails in all the same places that SIDF and SPF do? SPF has no problem with non-standard mailing list behaviour, it doesn't look at (2)822 header fields From / Sender / Resent-*. If you replace (Client IP Address) by (Valid DKIM Signature) then the similarity between SPF and SSP can be quite striking. Extreme application of SPF results in the rejection of mail that does not come from the right Client IP Address. Extreme application of SSP results in the rejection of mail that does not come with the right Valid DKIM Signature. It's really the same thing, at different layer in the OSI stack. Or is it? If all SSP were doing was to re-invent SPF at a different OSI layer, then no progress would be made; we would only squander the opportunity for better accountability that DKIM makes possible. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to unsigned messages
Dave Crocker: Stephen Farrell wrote: 1521Limit the application of SSP to unsigned messagesnew dkim Nobody0 [EMAIL PROTECTED]9 days ago9 days ago0 Proposal: REJECT, but some wording changes may be needed for the next rev, thread is [4] I mainly saw opposition to the change suggested in the issue, and little support, but some text clarifying changes were suggested (e.g. [5]). [4] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008424.html [5] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008467.html Would you please explain the basis for assessing that this topic got sufficient discussion and that there was rough consensus on it? See above I mainly saw... Summary of proposal: All text that causes SSP to be applied to an already-signed message needs to be removed. I would take this further: remove all text that says when to apply SSP. Instead, provide text that states the contribution that SSP can make under different conditions: mail with valid first-party signature, mail with valid third-party signature, and mail without valid signature. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to unsigned messages
Arvel Hathcock: I would take this further: remove all text that says when to apply SSP. Instead, provide text that states the contribution that SSP can make under different conditions: mail with valid first-party signature, mail with valid third-party signature, and mail without valid signature. I mostly agree with Wietse's proposal. Yes, I'm aware that diverges sharply from the current draft. I could get behind Wietse's proposal also if it hadn't started with I would take this further. I'm concerned with the this he refers to which encourages avoiding SSP completely in the presence of a verifiable signature from just anybody whom-so-ever. I view that notion as completely defeating SSP. I am not discouraging SSP. take this further refers to the deleted text that directly preceded it: All text that causes SSP to be applied to an already-signed message needs to be removed. I propose that we remove not only this text but also other text that says when to apply SSP. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to unsigned messages
Jim Fenton: Arvel Hathcock wrote: I would take this further: remove all text that says when to apply SSP. Instead, provide text that states the contribution that SSP can make under different conditions: mail with valid first-party signature, mail with valid third-party signature, and mail without valid signature. I mostly agree with Wietse's proposal. Yes, I'm aware that diverges sharply from the current draft. I could get behind Wietse's proposal also if it hadn't started with I would take this further. I'm concerned with the this he refers to which encourages avoiding SSP completely in the presence of a verifiable signature from just anybody whom-so-ever. I view that notion as completely defeating SSP. That's exactly what I was hoping wasn't being proposed. No worries. The proposed change is to focus the benefits that SSP can provide in scenarios as outlined above, not to discourage the deployment of SSP. One can do SSP lookup in all three scenarios, but the benefits will differ. If mail has only a valid third-party signature, then the receiver can use both the signer's reputation AND the statement in SSP (AND any number of other data points) to arrive at a conclusion on how to dispose of/label/whatever the message. If mail has no valid signature, then obviously the originator SSP is directly relevant (together with any number of other data points). And if mail has a valid first-party signature, SSP is pretty much redundant. I hope this clarifies things a little better than my previous terse statement. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to unsigned messages
Arvel Hathcock: No worries. The proposed change is to focus the benefits that SSP can provide in scenarios as outlined above, not to discourage the deployment of SSP. Could there be broader agreement on an SSP specification that lays out how to do an SSP lookup but doesn't rigidly mandate where to look or when to look? Instead, the spec would lay out several scenarios as examples; chief amongst those being when signatures do not match the From: domain? I have been thinking along those lines for the past week or so, recognizing that DKIM and SSP results will likely be used together with other data points that may get a higher or lower weight depending on receiver preferences. As you recognize, the easiest scenarios are the ones with valid first-hand signature and no valid signature. In the former case, the DKIM signature provides a data point, in the latter the case, SSP. The scenario with valid third-party signature provides two data points, one from the DKIM signature and one from SSP. Which of the two gets more authority is something that IMHO only the receiver can decide; just like the receiver decides on their weight relative to any other data points. This does not change fundamentally when there are more than one author. One reasonable approach seems to iterate over the list, up to some sane upper bound. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to unsigned messages
For the record, one minor correction for sloppy language. Wietse Wietse Venema: Arvel Hathcock: No worries. The proposed change is to focus the benefits that SSP can provide in scenarios as outlined above, not to discourage the deployment of SSP. Could there be broader agreement on an SSP specification that lays out how to do an SSP lookup but doesn't rigidly mandate where to look or when to look? Instead, the spec would lay out several scenarios as examples; chief amongst those being when signatures do not match the From: domain? I have been thinking along those lines for the past week or so, recognizing that DKIM and SSP results will likely be used together with other data points that may get a higher or lower weight depending on receiver preferences. As you recognize, the easiest scenarios are the ones with valid first-hand signature and no valid signature. In the former case, the DKIM signature provides a data point, in the latter the case, SSP. The scenario with valid third-party signature provides two data This should be: valid third-party signature only points, one from the DKIM signature and one from SSP. Which of the two gets more authority is something that IMHO only the receiver can decide; just like the receiver decides on their weight relative to any other data points. This does not change fundamentally when there are more than one author. One reasonable approach seems to iterate over the list, up to some sane upper bound. Wietse ___ 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
[ietf-dkim] Accidental versus malicous error (was: SSP assist DKIM)
Is no signature equivalent to a bad signature? Is a bad signature the result of malice or accident? Some don't distinguish between these cases, arguing that favoring bad signatures over no signatures only encourages criminals to send mail with bad signatures. For example: Doug Otis: This dubious strategy provides a significant incentive for bad actors to insert bogus DKIM signatures. Others believe that they can distinguish between malice and accident. For example: Charles Lindsey: If a verifier believes he can give a better service to his clients (less false positives, perhaps) by distinguishing whether the failure was in the body hash or in the header hash, or even by trying to reverse engineer the changes that had caused the previously good signature to become bad, then he is welcome to try. Now consider the case that you can't reverse engineer the damage. At this point you can't distinguish between malice or accident. Will you give no signature equal treatment to bad signature, or will you give mail with bad signatures (such as a valid header that was pasted on top of a forged body) more favorable treatment? Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue 1530 - replace use of term suspicious
Steve Atkins: On Dec 16, 2007, at 9:10 AM, Dave Crocker wrote: Jon Callas wrote: Dave Crocker wrote: With the use of language like suspicious, SSP is making value judgement on messages that do not satisfy SSP's criteria, even though those message well might be entirely legitimate. ... How about something like SSP Exception? Metaphorically, it works well with the programming use of the word exception. Folks, In the hope of trying to close some of the easy Issues, would folks comment on this specific proposal, or otherwise post comments seeking closure of the Issue? SSP exception works for me, and is better than suspicious, regardless of capitalization. +1. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Hostile to DKIM deployment
Damon: SSP does not help me decide which bank is real. Again, I know who my bank is. If I get a message from BoA or a message from the First Mountain Trust of Namibia, I believe I would not have any trouble distinguishing between the two. I don't expect burglars to put WARNING: BURGLARY IN PROGRESS signs on side walks. Likewise, I don't expect that criminal banks will announce their intentions in such an obvious manner as you are suggesting. As for your assertion that you know who your bank is, can you pick out the real bank from the list posted here: http://mipassoc.org/pipermail/ietf-dkim/2006q3/005884.html What is the relevance of this for the current effort? I have nothing against an SSP that says what mail if any a domain signs or sends. Like many, I would use that to throw away some mail. But it would be a mistake to position SSP as the solution for email phishing. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Hostile to DKIM deployment
I don't think SSP is hostile to the DKIM deployment, but helps its deployment because it will at least provide some avenue of protection for domains and receivers who don't wish to get into 3rd Party Trust Service dependencies where there is no standard definition and absolutely no guarantee of consistent results. By the way, speaking of trust and reputation services: SSP does not say that my bank's domain belongs to a real bank. SSP does not say that a criminal's domain belongs to a fake bank. SSP does not help me decide which bank is real. If anything requires a reputation service, then it is SSP not DKIM. DKIM can manage just fine with a local whitelist. I am aware that credibility on this list is inversely proportional to the number of messages posted, and I will post corrections like this infrequently. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The limits of DKIM and SSP
Scott Kitterman: On Sunday 09 December 2007 10:07, Wietse Venema wrote: After yesterday's massive agreement, today I'll expand some of my statements with examples, and expose some limits. Statement 1 With DKIM, The Signer Domain says I signed this mail. It does not approve content, or state that content is benign. The receiver decides whether to give this signature preferred treatment. There is little or no controversy about this aspect of DKIM. Having the bank's Signer Domain in my local address book, I can distinguish between mail that has The Bank's signature (known to be good) and mail that does not. When I get mail from a criminal bank with a name and logo similar to that of my bank, the criminal Signer Domain won't match any bank that I know I have a business relationship with, and I can treat it accordingly. Although I wrote that signers make no statement on content, there are valid reasons why a signer might want to do so. For example, an email security service provider might want to say I signed this mail and thus offer assurance that mail is free from malware. Of course they would leave any pre-existing signatures intact. Statement 2 With SSP, The Sender Domain says I send such and such mail: if any is signed, or not signed. This is primarily relevant for mail without valid signature by The Sender Domain. There is little or no controversy about this aspect of SSP. Agreed, particularly the without valid signature by The Sender Domain. Some position SSP as a tool against phishing. For example, SSP can make statements about mail that claims it is sent in The Sender Domain's name, urging receivers not to open any letters that lack a valid signature by The Sender Domain. Unfortunately, this protection is effective only under the assumption that the bad guys are stupid; namely that they will try to send mail in the name of my bank without a valid signature by my bank. But criminals don't necessarily play by the rules. I disagree. I think that while the difference is small, I believe there is worthwhile benifit to preventing what I would call exact domain forgery. This is not a complete solution to phishing (I'm not sure such a thing exists), but one small piece. While the difference between (for example - I didn't check to see if Paypal owns the alternate I show here) paypal.com and paypa1.com is small, it's a step. Specifically, SSP statements by my bank won't protect ME against mail from a Criminal bank with a name and logo similar to that of my bank. The Criminal bank will make it 100% SSP compliant and will specify the strictest policy settings. Just like the real bank, the Criminal's SSP will say Trust me. I am a high-value target. Agreed. Neither (necessarily) will the address book trick you describe in Statement 1. The address book trick is only one social engineering trick away from being on the good list. +--+ |Why would I believe the SSP from my bank, and not the SSP from the| |criminal bank? Based on SSP alone, both have equal credibility. | +--+ Why would criminal bank's SSP matter? SSP doesn't exist to help make positive assertions about good messages. It exists to identify messages that fall outside the senders policy (or whatever we decided the P stood for). Trying to assert Passes SSP as a criteria for acceptance would be a poor idea. Does the Bank's SSP matter? I assume your answer is yes. My point is that SSP alone cannot distinguish between mail from my Bank and mail from a Criminal who pretends to be a slightly different bank. It distinguishes only the stupid criminals who send mail in the Bank's name without signature by the Bank. As discussed under statement 1, mail from the criminal is easily exposed with a simple query against my local address book. The criminal Signer Domain won't match any banks that I know I have a business relationship with. I don't even have to go to an external reputation service for that. Conclusion We have a paradox where DKIM-BASE does not promise protection against phishing attacks, but it's near trivial to use for that purpose with a local address book; while SSP protection against phishing can be sidestepped near trivially because it is grounded in statements by a Sender Domain whose trustworthiness is unproven. Assuming SSP asserts something positive beyond what DKIM asserts. It doesn't. It allows a negative to be identified. It is not in the Bank's interest to say negative things about the Banks mail. Likewise, it is not in the Criminal's interest to say negative things about the Criminal's mail. SSP alone does not distinguish between mail from a Bank and mail from a Criminal who pretends to be a bank. That is SSP's dirty little secret
[ietf-dkim] The limits of DKIM and SSP
After yesterday's massive agreement, today I'll expand some of my statements with examples, and expose some limits. Statement 1 With DKIM, The Signer Domain says I signed this mail. It does not approve content, or state that content is benign. The receiver decides whether to give this signature preferred treatment. There is little or no controversy about this aspect of DKIM. Having the bank's Signer Domain in my local address book, I can distinguish between mail that has The Bank's signature (known to be good) and mail that does not. When I get mail from a criminal bank with a name and logo similar to that of my bank, the criminal Signer Domain won't match any bank that I know I have a business relationship with, and I can treat it accordingly. Although I wrote that signers make no statement on content, there are valid reasons why a signer might want to do so. For example, an email security service provider might want to say I signed this mail and thus offer assurance that mail is free from malware. Of course they would leave any pre-existing signatures intact. Statement 2 With SSP, The Sender Domain says I send such and such mail: if any is signed, or not signed. This is primarily relevant for mail without valid signature by The Sender Domain. There is little or no controversy about this aspect of SSP. Some position SSP as a tool against phishing. For example, SSP can make statements about mail that claims it is sent in The Sender Domain's name, urging receivers not to open any letters that lack a valid signature by The Sender Domain. Unfortunately, this protection is effective only under the assumption that the bad guys are stupid; namely that they will try to send mail in the name of my bank without a valid signature by my bank. But criminals don't necessarily play by the rules. Specifically, SSP statements by my bank won't protect ME against mail from a Criminal bank with a name and logo similar to that of my bank. The Criminal bank will make it 100% SSP compliant and will specify the strictest policy settings. Just like the real bank, the Criminal's SSP will say Trust me. I am a high-value target. +--+ |Why would I believe the SSP from my bank, and not the SSP from the| |criminal bank? Based on SSP alone, both have equal credibility. | +--+ As discussed under statement 1, mail from the criminal is easily exposed with a simple query against my local address book. The criminal Signer Domain won't match any banks that I know I have a business relationship with. I don't even have to go to an external reputation service for that. Conclusion We have a paradox where DKIM-BASE does not promise protection against phishing attacks, but it's near trivial to use for that purpose with a local address book; while SSP protection against phishing can be sidestepped near trivially because it is grounded in statements by a Sender Domain whose trustworthiness is unproven. In other words, SSP needs an external service to attest that the Sender Domain's self-declared SSP does indeed represent a bona fide business. Supposedly, criminals won't be able to purchase such attestation. This is the dirty secret behind SSP. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] SSP sender expectations
Hector Santos: [ Charset ISO-8859-1 unsupported, converting... ] Wietse Venema wrote: Perhaps an analogy from a different but familiar world will help. Consider DKIM or SSP as broadcast radio transmissions (or TV if you must). The point is that it is a UNIDIRECTIONAL thing. The sender doesn't know if anyone is receiving the signal, and they certainly can't force anyone to listen (or watch their TV program). Likewise, the sender of DKIM-enabled email doesn't know if the receiver implements DKIM or SSP, and they certainly can't force them to implement unenforceable statements that say deny. DKIM and SSP have no more enforcement power than broadcast radio. You don't know who receives the signal and you certainy can't force them to do anything with it. With the DKIM and SSP broadcast model, you can define the format of the signal and its meaning. That's all. If you want to control the receiver and deny mail, then you need a fundamentally different model. Yes Wietse. Thank you for highlighting the simple broadcaster/receiver model. It was very appropiate. By the way, I neglected to clarify my remark about fundamentally different model, so I will take the opportunity to correct that. Current email is primarily push technology. The problem therefore is authenticating the pusher. A fundamentally different model would be pull-based. For example, to receive mail from my bank, I would pull it from their website. I wouldn't have to worry if the mail is spoofed (it came from the bank's website, I have their DNS name and SSL cert), and the bank could easily claim that all other mail in their name is a forgery. Note that pull-based email technology is immune to the problems of forwarding, mailing list munging and third-party signatures. One implementation is for the bank to send a tiny email message with just a token, plus a plain old URL for legacy mail clients. As in early MIME days, legacy clients show ugly stuff to the user. Smart MTAs (or MUAs) would handle the download step transparently. There's nothing revolutionary in this. It's just basic application of a different email distribution model. In fact, that model can be built on top of the existing one. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comment about SSP Draft - MX lookup requirement
Hector Santos: Overall, although I do have many comments about the SSP draft, there is really just 1 thing that sticks out. Section 4.4, item 3: 3. The Verifier MUST query DNS for an MX record corresponding to the Originator Domain (with no prefix). This query is made only to check the existence of the domain name and MAY be done in parallel with the query made in step 2. If the result of this query is an NXDOMAIN error, the message is Suspicious and the algorithm terminates. NON-NORMATIVE DISCUSSION: Any resource record type could be used for this query since the existence of a resource record of any type will prevent an NXDOMAIN error. The choice of MX for this purpose is because this record type is thought to be the most common for likely domains, and will therefore result in a result which can be more readily cached than a negative result. This just seems out out of place for DKIM/SSP. The SMTP reality is that an MX may not be available and most production SMTP software will have logic or options for a specific NO MX rule: NO MX - 1 or more A record lookup send mail attempts. Hector, As the text states, the above test does not require that the MX record exists. It just requires that *something* exists. As long as something exists, the result of MX lookup will be no data or an MX record, but it won't be NXDOMAIN. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
Patrick Peterson: I (respectfully) disagree with Wietse. I think it is very important for the sender to be able to express their desire to the receiver for how to handle mail in specified circumstances. I do not believe expressing this desire constitutes telling receivers what to do. This is a very important point as many of the senders I know who want to deploy DKIM feel this is an important component. Large scale deployments of DKIM require significant time and testing before adequate confidence can be established of reliability. Once adequate confidence is established many senders want to request that receivers do not deliver unsigned or improperly signed messages. These senders are not under the illusion they can force receivers to do anything. But they feel it is a significant value to express their desire. I agree with the sentiment that senders must be able to indicate under what conditions mail is un/authentic. DKIM provides a more reliable tool to rank mail than looking at the FROM header. However, I disagree with the sentiment that senders can tell receivers to kill it, don't pass it on as expressed here. This implies that senders control the threshold at which receivers discard mail. I consider this unrealistic. More realistic, IMHO, is that receivers maintain control over their threshold, and that they use DKIM as a tool to rank mail against that threshold. Wietse pat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wietse Venema Sent: Friday, June 08, 2007 6:19 AM To: Hector Santos Cc: IETF DKIM WG Subject: Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues Hector Santos: I don't expect mail from this domain - kill it, don't tag it or mark it as bad for user's to see, kill it, don't pass it on. Its not ours! - If you do, it is no longer our responsibility as DKIM-BASE suggest it is. Enough is enough. I thought we already debunked the myth that SSP can tell receivers what they should do. It's a sender signing policy. It's not a receiver disposition policy. == === === Sender != Receiver Signing != Disposition I am of course assuming that this forum is conducting business in plain English, not some variant with radically different semantics. If my assumption is in error, please ignore this erroneous comment. Wietse ___ 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: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
Hector Santos: I don't expect mail from this domain - kill it, don't tag it or mark it as bad for user's to see, kill it, don't pass it on. Its not ours! - If you do, it is no longer our responsibility as DKIM-BASE suggest it is. Enough is enough. I thought we already debunked the myth that SSP can tell receivers what they should do. It's a sender signing policy. It's not a receiver disposition policy. == === === Sender != Receiver Signing != Disposition I am of course assuming that this forum is conducting business in plain English, not some variant with radically different semantics. If my assumption is in error, please ignore this erroneous comment. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Jim's issues - one more try
Issue#1: +1 - include use of XPTR as part of ssp-00 Issue#1: -1 - exclude use of XPTR from ssp-00 +1 Issue#2: +1 - Define how to use a TXT RR for SSP policies (with or without something else) Issue#2: -1 - Don't use TXT at all, only use new RRs for SSP +1 Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM blurb
Like many I was asked to for comments on DKIM after the RFC was announced. Below is my simplified, mostly correct, summary. Feel free to copy, modify, or distribute. Wietse What DKIM is DKIM (domain keys identified mail) is email authentication technology, developed in an IETF (internet engineering task force) working group. It allows recipients to identify the origin of email more reliably than by looking at its FROM address. Where DKIM software runs Typically DKIM software does not run on end-user systems. Instead, it runs on mail servers that send and receive mail across the Internet. For mail within an organization, there may be other ways to deal with email forgeries. How DKIM works With DKIM, a sending mail server stamps outgoing mail with a cryptographic signature of header and body content; a receiving server verifies the signature on incoming mail, using a public key that is stored in the DNS (domain name system) under a sender-specified domain name. The DKIM signature and other information are stored in an extra header inside the email message. What DKIM is not DKIM is not to be confused with S/MIME or PGP like technologies. While S/MIME etc. identifies the user who sends mail, the DKIM signature typically identifies the sending mail server or organization. The mail server operator needs to ensure that it will stamp only mail from appropriate users (for example, an organization's mail servers would stamp mail only from users on the organization's own networks). What DKIM can/cannot do DKIM typically allows a recipient to find out if mail from PAYPAL.COM was sent through a PAYPAL.COM mail server. However, DKIM does not tell the recipient whether or not REALLY-SECURE-PAYPAL.COM and other look-alike domains are owned by thieves, and whether mail from those domains can be trusted when it has a correct DKIM signature. DKIM as enabler for reputation services DKIM provides a way to identify email senders more reliably than by looking at the FROM address. To decide whether or not a DKIM signature can be trusted, users need to use reputation information, either information from the user's address book (I have done business with REALLY-SECURE-PAYPAL.COM before and I trust them) or from third-party reputation services that are still being developed. DKIM availability DKIM support is available for many major mail servers, including open source mail servers such as Sendmail and Postfix. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Hector Santos: This is exactly the same problem that the industry evolved to over the past two decades and what has brought us together here. The problem is dealing with the legacy market of old SMTP systems and how the bad guys use this to gain entry into systems. If that wasn't the problem then we would have FULL control of all anonymous transactions. Indeed. The evolutionary approach does not work. It has saddled us up with a series of legacy systems that we need to cope with. Instead, we need to get things right the first time. Therefore we need to discourage deployment until we have achieved the complete and perfect solution. After that point has been reached, the world will be perfect forever and nothing will ever need to be changed. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: I-D ACTION:draft-ietf-dkim-overview-04.txt
Tony Hansen: However, I'd like to hear some discussion on the issue: Should we put out a version now (without the SSP references), or hold off until SSP is totally finished? I would not wait with an Overview document until SSP is ready for prime time. I would encourage deployment of DKIM-base now so that we can gain useful experience. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: Additional lookups (was Re: [ietf-dkim] Re: 1368 straw-poll)
Charles Lindsey: On Thu, 01 Mar 2007 13:44:21 -, Wietse Venema [EMAIL PROTECTED] wrote: On a friendly internet with only cooperating parties, this might make sense. But the world has changed. With today's internet it would be a fundamental mistake to make more distinctions than: the signature was verified other If the verifier gives different treatments to different types of other, then the bad guys will exploit the verifier's behavior. And how do you stop verifiers doing that? There is no cure for stupidity, but I can try to educate. Verifiers will do as they think fit (i.e. what their clients will pay for), whatever our standards say. If some likely (though deprecated) verifier behaviour leads to exploits by the Bad Guys, and there is an easy way to counter the exploit (e.g. by clearer information in the SSP), then it would be wise to dopt it. Defence in depth is the term, I believe. SSP is not a cure for exploitable verifiers. Wrong solution for the wrong problem is the term, I believe. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: Additional lookups (was Re: [ietf-dkim] Re: 1368 straw-poll)
Charles Lindsey: On Wed, 28 Feb 2007 13:21:55 -, Hector Santos [EMAIL PROTECTED] wrote: There are three basic outcomes with a message: VALID SIGNATURE INVALID SIGNATURE NO SIGNATURE No, there are four basic outcomes with a message. You omitted UNVERIFIABLE SIGNATURE which just happens to be the one that this thread is all about. On a friendly internet with only cooperating parties, this might make sense. But the world has changed. With today's internet it would be a fundamental mistake to make more distinctions than: the signature was verified other If the verifier gives different treatments to different types of other, then the bad guys will exploit the verifier's behavior. The solution to the problem is not to complicate the protocol, but to avoid the mistake of giving different treatments to different types of other. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: Additional lookups (was Re: [ietf-dkim] Re: 1368 straw-poll)
Hector Santos: Wietse Venema wrote: If the verifier gives different treatments to different types of other, then the bad guys will exploit the verifier's behavior. Applying equal treatment should be done across the board, the valid and invalid, not just for the so called elite messages. It is with the exceptions and relaxed provisions where exploitation will take place, the FSUSP (FAILED SIGNATURE UNSIGNED STATUS PROMOTION) is one of them. Perhaps I wasn't clear enough. When a DKIM verifier gives unequal treatment to any of the following: - no signature - broken signature - unsupported signature - other failure Then the bad guys will send their forged mail in the way that receives the most favorable treatment. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] mutant message validation, was Base issue: multiple linked signatures
John Levine: From my perspective having a message have a valid signature with one implementation and having a broken signature with another is an incompatibility. I don't think that's speculation. ... No, it merely reflects a difference of opinion by the sites concerned as to what changes it will tolerate in a message before it recommends to its clients that the message should be dropped. It is not the job of our standard to dictate local policy issues at that level of detail. I agree that we are not dictating local policy. But I really think that it's our job to dictate the definition of what the signature validation algorithm is. As I've said before, everyone remains free to do whatever they want with messages whether or not the signature verifies, including applying various heuristics to develop opinions about unsigned messages. Perhaps some people are confusing verification and presentation. Verification: it is critical that all DKIM verifiers agree on what is a valid DKIM signature, without falling back on heuristics, such as heuristics to repair messages. Presentation: after the valid/invalid decision is irevocably made, it is up to application/policy to decide how/if things will be presented to users. Heuristics of various sorts can be useful in this domain, such as message repair, known signer associations, etc., but those heuristics must not determine the validity of the DKIM signature. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
