Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
On May 22, 2009, at 11:40 PM, John Levine wrote: >> When the body of the message has an open-ended length, the number >> of attempts to produce a collision might be within what now seems >> like a small number of attempts. > > If SHA256 is that weak, we have worse problems than spoofed DKIM > messages. Fortunately, nobody I know in the crypto community thinks > that it is. An open-ended body length places any hash algorithm at increased risk, especially sha-1 which is likely to remain in common use. However, with any hash algorithm, vulnerabilities are reduced whenever an attack must generate specific body lengths, rather than allowing variable body lengths be used in conjunction with various differential collision techniques. The difference is the ease of an attack that might be made possible through the use of a distributed network supported by millions of compromised computers. There remains a few prudent reasons for retaining the l= parameter: 1) better protects hash algorithms. 2) provides simple techniques to isolate prefixed or appended ads or notifications added by the incoming providers. Recipients remain better able to determine which message element had been signed, rather than blindly relying upon ambiguous A-R headers. 3) allows future schemes to encapsulate attachments separately without increased resource burdens. It should also be noted that DKIM has yet to fulfill its intended use. IPv6 has not become widely adopted where DKIM's features will have been more fully exercised. Most of the changes to RFC-4871 appear aimed at preventing recipients a means to independently assess incoming messages, and/or to differentiate incoming provider's content from that of the original sender. This effort significantly undermines the intent of the original RFC4871. Removal of explicit expiry assertions or copied header fields also servers to limit a recipient's ability to evaluate messages modified by incoming providers. Knowing what to trust, is equally important to knowing who is being trusted. -Doug ___ 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
> When the body of the message has an open-ended length, the number of > attempts to produce a collision might be within what now seems like a > small number of attempts. If SHA256 is that weak, we have worse problems than spoofed DKIM messages. Fortunately, nobody I know in the crypto community thinks that it is. R's, John ___ 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
On May 22, 2009, at 5:31 PM, John Levine wrote: >> Surely you do not suppose that a signature which covers only the >> From header (and that is a perfectly valis signature according to >> the document) is to be accepted as equally valuable to a signature >> that covers everything. > > Probably not, but that's because a dimwit who puts on cruddy > signatures is unlikely to earn a very good reputation. I really > REALLY do not plan to waste any time inventing heuristics to > evaluate the "quality" of a DKIM signature and I doubt anyone else > does, either. If you want people to accept your mail, be sure to > sign only good mail, and be sure to sign it in a way that bad guys > can't fake. John, I would agree signatures currently should cover the message body, but this might also include the message body length. A properly structured message should not be prone to attack without the attack being rather obvious. When the body of the message has an open-ended length, the number of attempts to produce a collision might be within what now seems like a small number of attempts. With millions of computers under centralized control, the time required to defeat an open-ended DKIM body hash with a reasonable set of signatures might be fairly brief. For most of these systems, users might not even be aware of the role their computer play in the attack. Anyone that signs a fairly generic message, where users could think they are being cc'd with comments added in the phish, might prove fairly effective at creating victims. The ability to keep the message format from being messed up by what is likely to become a deluge of provider ads would also be a benefit. After all, this was one of the driving benefits being sought when developing DKIM. It seems that DKIM combined with RFC 5451 and the loss of the l= parameter, this benefit is likely lost as well. That would be a shame. It would also be a shame to have people still wondering who sent which part of a DKIM signed message. -Doug ___ 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
>Surely you do not suppose that a signature which covers only the From >header (and that is a perfectly valis signature according to the >document) is to be accepted as equally valuable to a signature that >covers everything. Probably not, but that's because a dimwit who puts on cruddy signatures is unlikely to earn a very good reputation. I really REALLY do not plan to waste any time inventing heuristics to evaluate the "quality" of a DKIM signature and I doubt anyone else does, either. If you want people to accept your mail, be sure to sign only good mail, and be sure to sign it in a way that bad guys can't fake. R's, John PS: >It is Blatantly Obvious! Some things that are Blatantly Obvious are also Just Plain Wrong. ___ 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
On Thu, 21 May 2009 17:08:12 +0100, Dave CROCKER wrote: > Eliot Lear wrote: >> On 5/21/09 5:45 PM, Dave CROCKER wrote: >>> There is no concept of "responsibility for information behond l=". >> >> Sure there is. It is simply "unsigned" beyond the value of l=. > > You appear to be confusing the difference between the internals of how > DKIM > determines whether there is a valid signature, from fine-grained (output) > semantics about the message. DKIM merely says that a valid signature is > present or it isn't. It makes no statement about differential coverage > of the > message. Rubbish! If the verifier reports there is no valid signature (or the signature that is present is broken), then all bets are off. But if it reports that a valid signature exists, then a perfectly reasonable question, to which the verifier should be prepared to answer, is "Fine, so exactly what is it that was signed?". And since DKIM defines very clearly what is covered by the signature (a list of headers, plus part or the whole of the body), that is clearly useful information which DKIM has conveyed and attested. Sure, the Spec does not say that is useful information, but why should it? It is Blatantly Obvious! Surely you do not suppose that a signature which covers only the From header (and that is a perfectly valis signature according to the document) is to be accepted as equally valuable to a signature that covers everything. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
> One of the reasons l= came to be was that we wanted to have as many valid > signatures out there as quickly as possible, so as to provide a reasonable > alternative basis for reputation. There was the presumption that the mailing > list software would lag, and it has. Now we know that one MAJOR piece of > mailing list software can be made to behave, and we know how to accommodate > it if it doesn't. But in order to preserve the signature, everyone would > essentially have to start using l=. I still don't get it. For one thing, the real MAJOR list software on the net is Yahoo Groups and Google Groups, each of which I would expect handles more discussion list mail than everything else combined, and neither of which will ever preserve a signature. But more to the point, if the goal is to maximize the amount of signed mail, the obvious change to make to list software is to make it sign its outgoing mail. That makes 100% of the mail from its lists signed. Why would you waste time with complicated kludges that under the most optimistic assumptions would only get a small fraction of the mail signed? By the way, both Yahoo Groups and Google Groups put on a nice fresh DKIM signature of their own, so 100% of their mail is signed today. Yahoo strips off incoming signatures, Google doesn't. Google adds an Authentication-Results: header so if you care and you trust them you can see whether they thought the incoming signature was good. R's, John ___ 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
One of the reasons l= came to be was that we wanted to have as many valid signatures out there as quickly as possible, so as to provide a reasonable alternative basis for reputation. There was the presumption that the mailing list software would lag, and it has. Now we know that one MAJOR piece of mailing list software can be made to behave, and we know how to accommodate it if it doesn't. But in order to preserve the signature, everyone would essentially have to start using l=. I think that is the real question on the table, as to whether that is advisable. There are legitimate reasons to say that it is, and other reasons to say that it is not. Eliot ___ 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
>> My recollection of the debate about l= is that there were about as >> many theories about the point of l= as there were people promoting it. >> The main theory I remember was about hypothetical mailing lists that >> were too incompetent to filter incoming spam so the list recipients >> would do it based on the signatures of messages that passed through >> the list. > > Except we now know that one major piece of list software can preserve the > signature, depending on whether subject is signed / preserved. I don't think anyone denies that there are some cases when a signature will survive some mailing lists, although the list software I've seen is all moving in the other direction -- mj2 will remove and flatten MIME parts and Yahoo groups rewrites HTML to add footers, for example. The question that I've never seen addressed is why bother? Why would you want to filter list mail based on the contributor's signature rather than the list's signature? If a list were having trouble with spam leaking through, would you expect the list manager to adjust the config to leak more perfectly, or fix the leak? Over the past two decades mailing lists have developed use all sorts of techniques to manage what gets onto the list and to keep out unwanted mail, and I've never seen a plausible explanation of why anyone would expect that to reverse so completely that list recipients would need to do per-message spam filtering. R's, John PS: We do bozo filtering of list mail, but that's easy -- you already know if the mail is from the list, so if the From: header says you know who, you ditch it. That's two lines of procmail. ___ 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
On May 21, 2009, at 10:30 PM, Eliot Lear wrote: >> My recollection of the debate about l= is that there were about as >> many theories about the point of l= as there were people promoting >> it. The main theory I remember was about hypothetical mailing >> lists that were too incompetent to filter incoming spam so the list >> recipients would do it based on the signatures of messages that >> passed through the list. > > Except we now know that one major piece of list software can > preserve the signature, depending on whether subject is signed / > preserved. While mailing lists are common, it seems doubtful mailing lists will be where the l= feature adds much value. It is fairly common to find notices and ads added to messages. Having the length of the message body explicitly defined allows signatures to be checked and added content identified without tracking every iterative hash value. Unlike OpenPGP or S/Mime, the message does not contain a structure that might be visible to recipients, but this creates some risk. Some providers might even wish to prevent MUAs a means to verify DKIM signatures and thereby remove a means to ascertain exactly what portion of the message had been signed, as might be revealed by the l= parameter. When a provider does not offer DKIM signature checking as part of their service, adding the l= feature ensures DKIM signatures in general remain more reliable. A declared body length ensures the signature remains robust and more able to endure varied use. A partially signed set of the body parts, other than attachments, represent a reasonable basis upon which to reject a message as being deceptive. Perhaps an extension to DKIM might even include a signed header containing attachment hashes. One other aspect to keep in mind involves a growing threat caused by bot-nets. Hashes are quickly defeated with rainbow tables. Not having a body length asserted by a DKIM signature header allows the generation of hash lists by simply extending a phish body and recording results at each length extension. Millions of systems controlled by bad actors can generate partial rainbow tables and be queried against intercepted message signature hashes to improve the odds of generating convincing spoofs. By having DKIM signatures explicitly declare body length, this then requires significantly greater resources to build rainbow tables. With storage and bot-net growth, estimates of the time to defeat hashes may need further review. Causing the generation of rainbow tables to be more resource intensive provides another possible benefit of the l= feature. The current impetus for recent changes to DKIM seem aimed at increasing dependence upon the providers performing DKIM signature checks rather than allowing MUAs a means to retain this ability when needed. This strategy may even make DKIM appear too unreliable within current email infrastructure for conducting commerce. These changes seem unlikely to improve DKIM, nor should the ultimate goal be to only allow a DKIM state of Signed/Not Signed. This takes DKIM down a path likely to cause complaints and to generate a greater uncertainty which will lead to more victims. Signed/Not Signed does not represent a result that can be made robust, nor made to encompass DKIM's modes of use. Don't expect DKIM to adopt the limitations of authorization strategies as a desired goal. DKIM may not have been signed by the Author Domain, which requires more than just a lock-symbol. In addition, the body of the DKIM message may have been appended to or prefixed. A body length allows a quick means to determine which. How are the suggested "simplifications" to DKIM beneficial when they increase the odds of recipients finding legitimate signatures marked invalid, or when they make it more difficult for signers and recipient to mitigate replay abuse? Leave DKIM as is and allow time to shape a best practices document. Don't underestimate what a MUA is able to convey. -Doug ___ 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
On 5/22/09 12:40 AM, John Levine wrote: > I don't get it. Yes, if you don't care about the body of a message, > using l=0 is mostly (not entirely) harmless, but I don't see that it > solves any problem. What's the advantage of using l=0 versus signing > the message the usual way? The speed difference is imperceptible. > Are these messages unusually likely to go via a path that smashes the > body and would break a regular signature? > I stated the case, but I think you're right, John. Why bother is indeed a good question. My only answer would be a minor performance gain if one were either processing or generating a whole lot of them. And it's very minor. > Also, the reason it's only mostly harmless is that it's still subject > to replay attacks if a bad guy gets such a message, pastes on a spammy > body, and then resends it to a million random people, presumably > thereby destroying whatever reputation the signer had. > Well, right, but the mitigation for that is the code that does the verifying. > >> The whole point of l= was to say that beyond it you should treat the >> content as suspicious. >> > My recollection of the debate about l= is that there were about as > many theories about the point of l= as there were people promoting it. > The main theory I remember was about hypothetical mailing lists that > were too incompetent to filter incoming spam so the list recipients > would do it based on the signatures of messages that passed through > the list. > Except we now know that one major piece of list software can preserve the signature, depending on whether subject is signed / preserved. Eliot ___ 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
>I find your arguments largely unconvincing. > >> Firstly, one expressed use case for l= is "l=0" - in other words, don't >> sign any of the body. In that case I can put any body content in there >> I like, and it'll still be validly signed. > >There are specific applications for such a case, and most of them are, >in my experience, programmatic, where there is no body, or where the >body is merely a comment (I've seen both forms commonly used). I don't get it. Yes, if you don't care about the body of a message, using l=0 is mostly (not entirely) harmless, but I don't see that it solves any problem. What's the advantage of using l=0 versus signing the message the usual way? The speed difference is imperceptible. Are these messages unusually likely to go via a path that smashes the body and would break a regular signature? Also, the reason it's only mostly harmless is that it's still subject to replay attacks if a bad guy gets such a message, pastes on a spammy body, and then resends it to a million random people, presumably thereby destroying whatever reputation the signer had. >The whole point of l= was to say that beyond it you should treat the >content as suspicious. My recollection of the debate about l= is that there were about as many theories about the point of l= as there were people promoting it. The main theory I remember was about hypothetical mailing lists that were too incompetent to filter incoming spam so the list recipients would do it based on the signatures of messages that passed through the list. R's, John ___ 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
Wietse Venema wrote: >> 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. DKIM's pathetic state is your case. -- Sincerely Hector Santos http://www.santronics.com ___ 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] Features that could be reconsidered as part of the bis process
+1 -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Thursday, May 21, 2009 10:45 AM To: Eliot Lear Cc: DKIM WG Subject: Re: [ietf-dkim] Features that could be reconsidered as part of the bis process Eliot Lear wrote: > The whole point of l= was to say that beyond it you should treat the > content as suspicious. Eliot, Since DKIM Signature does not make statements about the differential handling of content, signed or unsigned, I'm not clear what you base this assertion on. Can you clarify? As I understand DKIM Signature, there is are validly signed messages (with their identifiers) and there are all other messages, and that binary distinction is the limit of DKIM semantics. You appear to be going beyond the specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
On May 21, 2009, at 10:43 AM, Eliot Lear wrote: > > And see my other message. I also question the value of l=. All I > was trying to say here was that the risks are well documented and > easily mitigated. Agreed. There are many areas beyond the scope of DKIM that might be of similar concern. When an MUA only displays friendly-names that are signed with a g= restricted keys, this would represent another area of concern. DKIM results are unlikely to always provide simple answers nor will it ensure simple annotations will be sufficient. Sorry, but DKIM is attempting to retrofit security into highly diverse environments and uses. There are no simple solutions. While daily observing millions of compromised systems operating from centralized control, the concept of being able to iteratively append junk to the end of a phish body until it collides with a signed body hash appears to make defeating the hash easier. Calculations of difficulty for doing this may need to consider today's environment. The l= parameter should make this more difficult. This has been raised because a few have also suggested expiry is also not needed. Having these arrows at the ready in the quiver allows a means to respond with far less disruption than would result without these features being available. Are MUA vendors unable to handle the information present within a) the DKIM signature? b) RFC 5451 results? If simple answers are required, use S/MIME or OpenPGP. DKIM provides the flexibility to handle a diversity of uses and environments. Such flexibility demands greater care when MUAs attempt to apply annotations. And yes, these annotations may be required to indicate, strip, or split unsigned message portions. It is too soon to tell what features will be needed and how best they can be used. What is clear, there are no simple answers for whether an entire message is to be annotated or not. When a message is being signed by g= restricted keys, even the friendly name should be excluded. -Doug ___ 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
On 5/21/09 6:08 PM, Dave CROCKER wrote: >> I believe this was explicitly stated elsewhere, like on this list. > > > But that's not in the spec. > That's because the topic of what a verifier does with a message was probably viewed as out of scope. But that doesn't imply, as you agreed, that the application of certain rules based on garbage at the end should not occur. >>> If such behaviors are necessary to make l= meaningful and useful -- >>> and your line of frankly reasonable thinking does seem to imply >>> this, though I doubt it was your intention -- then the specification >>> for this bit of mechanism is seriously deficient. >> >> Perhaps, but why do you think so? > > You've been relying on interpretations that aren't in the > specification. If you restrict discussion to only using semantics > from the specification (with the Update) then I'm not understanding > what value proposition applies. I think you are confusing uses for interpretations. Of course information beyond the l= value should be treated with some suspicion. Otherwise all that stuff that Steve mentioned can happen in some cases. > And by the way, my original question was about who is using the > feature and finding it valuable. Not about theoretical scenarios, but > experience based on two years of possible use. And see my other message. I also question the value of l=. All I was trying to say here was that the risks are well documented and easily mitigated. Eliot ___ 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
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. -- Sincerely Hector Santos http://www.santronics.com ___ 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
Dave CROCKER wrote: > And by the way, my original question was about who is using the feature and > finding it valuable. Not about theoretical scenarios, but experience based > on > two years of possible use. The archives are your friends. This has been stated innumerable times with real-life statistics. Mike ___ 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
Dave CROCKER wrote: > > Eliot Lear wrote: >> On 5/21/09 4:45 PM, Dave CROCKER wrote: >> I think the point is that you can't make assertions of responsibility >> for the information beyond l=. > > Eliot, > > But with respect to "assertions" about a message, DKIM only has > valid-vs-unsigned. Unfortunately, that was a policy decision and it is conflictive with the realistic technical values of a malfunctioning operation. There are three technical states software provides: signed and valid signed and invalid unsigned To eliminate one is a policy decision. -- Sincerely Hector Santos http://www.santronics.com ___ 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
Eliot Lear wrote: > On 5/21/09 5:45 PM, Dave CROCKER wrote: >> There is no concept of "responsibility for information behond l=". > > Sure there is. It is simply "unsigned" beyond the value of l=. You appear to be confusing the difference between the internals of how DKIM determines whether there is a valid signature, from fine-grained (output) semantics about the message. DKIM merely says that a valid signature is present or it isn't. It makes no statement about differential coverage of the message. Separate from text that defines the verification algorithm, can you point to text in the Signature specification that refers to differential semantics or differential output from the verifier? >>> That was always the implication, right? >> It is no where in the specification and I believe it never was. > > I believe this was explicitly stated elsewhere, like on this list. But that's not in the spec. >>> So now you're a mail firewall and you see lots of URLs tagged at the >>> end, with nobody asserting responsibility. That's an indicator that >>> there is a problem. What one does with that problem is well beyond >>> the scope of DKIM, but one could easily see several different courses >>> of action: >> >> Now you inventing behaviors that go far beyond the specification. > > Well, that is what I wrote (I concede I don't know the difference > between well beyond an far beyond ;-) Maybe lateral vs. vertical? a well can be deep and far can be to the horizon...? >> If such behaviors are necessary to make l= meaningful and useful -- >> and your line of frankly reasonable thinking does seem to imply this, >> though I doubt it was your intention -- then the specification for >> this bit of mechanism is seriously deficient. > > Perhaps, but why do you think so? You've been relying on interpretations that aren't in the specification. If you restrict discussion to only using semantics from the specification (with the Update) then I'm not understanding what value proposition applies. And by the way, my original question was about who is using the feature and finding it valuable. Not about theoretical scenarios, but experience based on two years of possible use. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
On 5/21/09 5:45 PM, Dave CROCKER wrote: > > > Eliot Lear wrote: >> On 5/21/09 4:45 PM, Dave CROCKER wrote: >> I think the point is that you can't make assertions of responsibility >> for the information beyond l=. > > Eliot, > > But with respect to "assertions" about a message, DKIM only has > valid-vs-unsigned. > > There is no concept of "responsibility for information behond l=". Sure there is. It is simply "unsigned" beyond the value of l=. > > >> That was always the implication, right? > > It is no where in the specification and I believe it never was. I believe this was explicitly stated elsewhere, like on this list. > > > >> So now you're a mail firewall and you see lots of URLs tagged at the >> end, with nobody asserting responsibility. That's an indicator that >> there is a problem. What one does with that problem is well beyond >> the scope of DKIM, but one could easily see several different courses >> of action: > > > Now you inventing behaviors that go far beyond the specification. Well, that is what I wrote (I concede I don't know the difference between well beyond an far beyond ;-) > > If such behaviors are necessary to make l= meaningful and useful -- > and your line of frankly reasonable thinking does seem to imply this, > though I doubt it was your intention -- then the specification for > this bit of mechanism is seriously deficient. Perhaps, but why do you think so? Eliot ___ 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
Eliot Lear wrote: > On 5/21/09 4:45 PM, Dave CROCKER wrote: > I think the point is that you can't make assertions of responsibility > for the information beyond l=. Eliot, But with respect to "assertions" about a message, DKIM only has valid-vs-unsigned. There is no concept of "responsibility for information behond l=". > That was always the implication, right? It is no where in the specification and I believe it never was. > So now you're a mail firewall and you see lots of URLs tagged at the > end, with nobody asserting responsibility. That's an indicator that > there is a problem. What one does with that problem is well beyond the > scope of DKIM, but one could easily see several different courses of action: Now you inventing behaviors that go far beyond the specification. If such behaviors are necessary to make l= meaningful and useful -- and your line of frankly reasonable thinking does seem to imply this, though I doubt it was your intention -- then the specification for this bit of mechanism is seriously deficient. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
On 5/21/09 4:45 PM, Dave CROCKER wrote: > > > Eliot Lear wrote: >> The whole point of l= was to say that beyond it you should treat the >> content as suspicious. > > > Eliot, > > Since DKIM Signature does not make statements about the differential > handling of content, signed or unsigned, I'm not clear what you base > this assertion on. Can you clarify? > > As I understand DKIM Signature, there is are validly signed messages > (with their identifiers) and there are all other messages, and that > binary distinction is the limit of DKIM semantics. You appear to be > going beyond the specification. I think the point is that you can't make assertions of responsibility for the information beyond l=. That was always the implication, right? So now you're a mail firewall and you see lots of URLs tagged at the end, with nobody asserting responsibility. That's an indicator that there is a problem. What one does with that problem is well beyond the scope of DKIM, but one could easily see several different courses of action: 1. stripping the URLs 2. quarantining the entire message 3. posting a warning IN the message But again, this is all really academic, depending on the point of actually USING l=. How can it LEGITIMATELY be used. We can find ways to deal with miscreants using l=, but it may not be worth it if we can't find legitimate uses... Eliot ___ 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
Eliot Lear wrote: > The whole point of l= was to say that beyond it you should treat the > content as suspicious. Eliot, Since DKIM Signature does not make statements about the differential handling of content, signed or unsigned, I'm not clear what you base this assertion on. Can you clarify? As I understand DKIM Signature, there is are validly signed messages (with their identifiers) and there are all other messages, and that binary distinction is the limit of DKIM semantics. You appear to be going beyond the specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
On 5/20/09 11:42 PM, Murray S. Kucherawy wrote: > Indeed, Outlook will opt to render an HTML part over a text part whenever > given the choice. Thus, if you sign only the text/plain portion of a > message and an attacker appends a text/html part, the unsigned HTML > version will be rendered even if completely different from the text/plain > part, and DKIM would give that a thumbs-up. > The conditions anticipated by l= was the limited case where a mailing list would append bits of information, such that the rest of the signature could be retained. As John has pointed out, that is challenging because of all of the rewriting that goes on. So I think we need to back up and decide whether it's worth arguing over whether a behavior change in the base is something we want to encourage. I don't have an opinion on that at the moment. Eliot ___ 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
Steve, I find your arguments largely unconvincing. > Firstly, one expressed use case for l= is "l=0" - in other words, don't > sign any of the body. In that case I can put any body content in there > I like, and it'll still be validly signed. > There are specific applications for such a case, and most of them are, in my experience, programmatic, where there is no body, or where the body is merely a comment (I've seen both forms commonly used). > Another use case is to use l= to sign a text part of an email, but not > to sign an attachment. In that case I can obviously replace the > attachment > with my own content, but depending on the details of the email structure > I may well be able to replace the text section as rendered to the user > as well. > This depends entirely on MIME multipart/alternative. Any reasonable implementation would drop a message that was signed that offered an alternate part beyond the l= length. > Another use case is to set l= to the entire length of the email as sent. > This case is a little less nonsensical than the others (though the > supposed > benefit it offers is not clear). I can still append raw content. > Depending on > the structure of the email I may well be able to have that appended > content > displayed in place of the original content. This is harder to exploit > such that > you can entirely replace the original content than the other cases, > but given > multipart mime and html there's no way I'd say it's impossible. > And another thing to point out is that even absent the signature, why would a message not be treated as suspicious if it had to parts of the same type (again, speaking of multipart/alternative)? My own (painful) experience is that this is the default for one of the most widely used UAs. > (And, if we're talking phishing attacks, which is one of the supposed > risks, > then I can put a very effective phishing attack in just the footer of > a message > anyway - the place people expect to find "Contact Us" or "Log in to your > account" or "Secure your access" links). > The whole point of l= was to say that beyond it you should treat the content as suspicious. Eliot ___ 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
On Wed, 20 May 2009 17:55:53 +0100, Dave CROCKER wrote: > Steve Atkins wrote: >> It means that I can, for example, take one copy of a service notice >> from my bank, leave the headers the same and replace the URLs >> in the body of the message to links to my website, then send it >> out to a hundred thousand people - and it would be validly signed >> by the bank. (The only user-visible content I wouldn't be able to >> change is the subject line). > This sounds like a plausible and serious scenario. Even with l>0, it > suggests a > line of attack -- by adding malicious text that appears to be part of > the bank > notice. Only if the bank was stupid enough to sign with l=0 in the first place. Clearly people who know they are phishing targets will not have l= tags at all. But the vast majority of email senders are not phishing targets. > > What is the counter-argument, in favor of retaining l= ? l=0 might be appropriate for Usenet control messages, where the important information is entirely in the headers. Even if l= were used it would help, since currently the commonest cause of Usenet control message failures is extra white lines tagged on the end in transit. l=0 would also be appropriate when other precautions were being taken to authenticate the bidy (e.g. Content-MD5, where the Content-MD5 header itself was included in the signature). And l= is always suitable when the end of the message is marked clearly in some other way, so that an addition is immediately seen as such. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
Steve Atkins wrote: > On May 20, 2009, at 4:31 PM, Michael Thomas wrote: > >> That's all DKIM guarantees. It's >> not in DKIM's scope to tell mail receivers what to do with the >> message, signed text or otherwise. Stupid receivers are free as >> always >> to do stupid things. Smart receivers are free as always to do smart >> things. As is ever was. > > Sure. The question is whether we want to have the spec encourage smart > behavior or encourage stupid behavior. > > The existence of l= certainly allows stupid behavior, and probably > encourages it. > > Cheers, >Steve Hence the DKIM policy hypocrisy. Policy Protocols are not being worked out, yet, we have all these questionable subjective policy based decisions being made to the DKIM base protocol that really are not universal agreements, and like much of the decisions made based on rough consensus, DKIM has been crippled and stagnated in many ways. There are useful ideas for l= and like the cautions we can apply to many useful ideas, this is no different. If a feature or idea usefulness or lack of was obvious that would be one thing, but it isn't. DKIM needs stability so that WIDER ADOPTION of implementators across all markets and operations can a) take it seriously to see how it can provide a payoff, b) see how it integrated into their frameworks and c) see how policy can be wrapped around it. -- Sincerely Hector Santos http://www.santronics.com ___ 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
Hi Steve, At 15:41 20-05-2009, Steve Atkins wrote: >Remember that we're considering the content of the message as >displayed to the end user here, not the traffic on the wire. If I can >control the content of the message as it's displayed to the recipient, >then the fact that I only have limited control as to the changes I can >make to the bytes on the wire is pretty much irrelevant. DKIM is not end to end. We only have to preserve the validity of the DKIM signature up to the DKIM verifier. "l=" was introduced because some mailing lists appends (sometimes it's more than that) a footer to the message. I tested "l=" with Mailman a few years back and the DKIM verification was successful even if a footer was added along the path between the signer and verifier. I don't think we should mix the content of the message with "signed" body. If the verifier passes the "unsigned" part without additional checks, there will be abuse. >But when we're talking about the benefits of something you can't If I recall correctly, the feature was added to fulfill one of the requirements. >There are a few, exceptional cases where using l= to preserve a DKIM >signature via a forwarder that would otherwise break it would actually >work (a sender choosing to use l= to sign the entire length of their >message sending plain text mail to a mailing list that does not modify >the body of the message other than appending a footer and does not >modify the signed headers - no From, Subject, Reply-To changes - for >instance). Even if you use the "l=", you can still get end up with a broken signature because of the subject tag. The Reply-To doesn't usually break the signature. Regards, -sm ___ 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
On May 20, 2009, at 2:42 PM, Murray S. Kucherawy wrote: > On Wed, 20 May 2009, Steve Atkins wrote: >> Another use case is to use l= to sign a text part of an email, but >> not to sign an attachment. In that case I can obviously replace the >> attachment with my own content, but depending on the details of the >> email structure I may well be able to replace the text section as >> rendered to the user as well. > > Indeed, Outlook will opt to render an HTML part over a text part > whenever given the choice. Thus, if you sign only the text/plain > portion of a message and an attacker appends a text/html part, the > unsigned HTML version will be rendered even if completely different > from the text/plain part, and DKIM would give that a thumbs-up. Outlook gives a thumbs-up to domain MTA authorizations as the source regardless of other domains also sending through the MTA. RFC5451 intentionally fails to provide MTA identities that could have enabled MUAs a means to annotate questionable authorizations. It remains fairly impractical and unsafe to rank domains based upon authorization of widely shared MTAs under different entities' control. Many large corporations share outbound MTAs for many reasons. Bad actors will have little trouble defeating the facade of MTA authorization and thereby create many victims. If Outlook does something equally as reckless as annotating unsigned content as being signed, that illustrates bad MUA design, not a bad protocol. The DKIM signature is normally unseen. Those adding annotations must be held accountable. Unlike authorization schemes, at least DKIM indicates _exactly_ what portion of message was signed, and specifically which domain added the signature. Those signing messages may decide to be explicit about the length of their message. Doing so better ensures notifications and ads that might be added by a recipient's provider will not impair annotations of signed message portions. Just as DKIM currently separates the body hash from that of headers, a header could include verification hashes for attachments as well. This would move performing hashes over large objects to the senders and recipients. Having the l= parameter in place enables this type of trade-off. Large MTAs will be performing may operations of related to verifying compliance, or perhaps doing mash-ups. The burden placed upon these systems can be reduced by a practice of creating separate authentication containers for attachments. There are competing companies introducing these products today. It seems reasonable to expect that soon this feature will find good use. DKIM is extremely explicit about what is and is not signed. Receiving a message where no message body is annotated as being signed should be accompanied by a warning. DKIM would become fairly inflexible when every feature must accommodate only one type of use. Removing DKIM features will not ensure good MUA design. There are many issues of equal concern not mitigated by removal of feature flexibility. If some MUA gets it wrong, there will be other better choices available. -Doug ___ 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
Steve Atkins wrote: > On May 20, 2009, at 4:31 PM, Michael Thomas wrote: > >> Steve Atkins wrote: >>> On May 20, 2009, at 3:57 PM, Michael Thomas wrote: Steve Atkins wrote: > Remember that we're considering the content of the message as > displayed to the end user here, No we're not. That has never been in the scope of the DKIM effort. >>> Even if it weren't section 8.1 of the existing RFC, it's pretty >>> obvious that a security issue that allows an attacker to create a >>> validly signed email with their own content without access to the >>> associated private key would be in scope for discussion. >> They cannot alter the signed text. > > They can't alter the signed *bytes*. They *can* alter the signed text. > That's the crux of the issue. No they can't. At least not without invalidating the signature. Crux dismissed. Mike ___ 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
On May 20, 2009, at 4:31 PM, Michael Thomas wrote: > Steve Atkins wrote: >> On May 20, 2009, at 3:57 PM, Michael Thomas wrote: >>> Steve Atkins wrote: Remember that we're considering the content of the message as displayed to the end user here, >>> No we're not. That has never been in the scope of the DKIM effort. >> Even if it weren't section 8.1 of the existing RFC, it's pretty >> obvious that a security issue that allows an attacker to create a >> validly signed email with their own content without access to the >> associated private key would be in scope for discussion. > > They cannot alter the signed text. They can't alter the signed *bytes*. They *can* alter the signed text. That's the crux of the issue. > That's all DKIM guarantees. It's > not in DKIM's scope to tell mail receivers what to do with the > message, signed text or otherwise. Stupid receivers are free as > always > to do stupid things. Smart receivers are free as always to do smart > things. As is ever was. Sure. The question is whether we want to have the spec encourage smart behavior or encourage stupid behavior. The existence of l= certainly allows stupid behavior, and probably encourages it. Cheers, Steve ___ 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
Steve Atkins wrote: > On May 20, 2009, at 3:57 PM, Michael Thomas wrote: > >> Steve Atkins wrote: >>> Remember that we're considering the content of the message as >>> displayed to the end user here, >> No we're not. That has never been in the scope of the DKIM effort. > > Even if it weren't section 8.1 of the existing RFC, it's pretty > obvious that a security issue that allows an attacker to create a > validly signed email with their own content without access to the > associated private key would be in scope for discussion. They cannot alter the signed text. That's all DKIM guarantees. It's not in DKIM's scope to tell mail receivers what to do with the message, signed text or otherwise. Stupid receivers are free as always to do stupid things. Smart receivers are free as always to do smart things. As is ever was. Mike ___ 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
On May 20, 2009, at 3:57 PM, Michael Thomas wrote: > Steve Atkins wrote: >> Remember that we're considering the content of the message as >> displayed to the end user here, > > No we're not. That has never been in the scope of the DKIM effort. Even if it weren't section 8.1 of the existing RFC, it's pretty obvious that a security issue that allows an attacker to create a validly signed email with their own content without access to the associated private key would be in scope for discussion. Cheers, Steve ___ 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
Steve Atkins wrote: > Remember that we're considering the content of the message as > displayed to the end user here, No we're not. That has never been in the scope of the DKIM effort. >>> (though the supposed benefit it offers is not clear) >> You forgot "to me". > > Not really. I don't think the supposed benefit clear to anyone, > including those who are interested in including the feature. Speak for yourself, please. And the archives for this -- and everything else you've brought up -- are your friends. Mike ___ 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
Murray S. Kucherawy wrote: > Indeed, Outlook will opt to render an HTML part over a text part whenever > given the choice. Thus, if you sign only the text/plain portion [...] Seriously: how signers and receivers use DKIM information is WAY outside of the scope of this working group. To read the hand wringing here you'd think that spam filter writers are complete idiots. They aren't. Mike ___ 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
On May 20, 2009, at 2:53 PM, Michael Thomas wrote: > Steve Atkins wrote: >> On May 20, 2009, at 2:17 PM, Michael Thomas wrote: >>> Steve Atkins wrote: Why would you want to sign email as something you vouched for, while still enabling anyone to replace the content of the email with something else without invalidating that signature? >>> You can't replace it; you can only append to it. >> That's likely wrong, depending on the details of the l= usage. > > No I'm not. > >> Firstly, one expressed use case for l= is "l=0" - in other words, >> don't >> sign any of the body. In that case I can put any body content in >> there >> I like, and it'll still be validly signed. > > That's still appending. > > >> Another use case is to use l= to sign a text part of an email, but >> not >> to sign an attachment. > > That's still appending. >> Another use case is to set l= to the entire length of the email as >> sent. > > That's still appending. It's only appending if you don't care about the email itself, just the protocol. Remember that we're considering the content of the message as displayed to the end user here, not the traffic on the wire. If I can control the content of the message as it's displayed to the recipient, then the fact that I only have limited control as to the changes I can make to the bytes on the wire is pretty much irrelevant. > DKIM only talks about taking responsibility, and only for the parts > that > are signed. How an evaluator deals with the unsigned parts of a > message > is outside of the scope of DKIM. But when we're talking about the benefits of something you can't constraint your discussion to just the details of the protocol - how it will be used, and how it will be attacked, in use are the core of what's important, and definitely within the scope of a discussion about whether a feature provides a benefit or not. > > (though the supposed benefit it offers is not clear) > > You forgot "to me". Not really. I don't think the supposed benefit clear to anyone, including those who are interested in including the feature. There have been a couple of concrete examples suggested, but they mostly don't actually make any sense when you dig into the details. There are a few, exceptional cases where using l= to preserve a DKIM signature via a forwarder that would otherwise break it would actually work (a sender choosing to use l= to sign the entire length of their message sending plain text mail to a mailing list that does not modify the body of the message other than appending a footer and does not modify the signed headers - no From, Subject, Reply-To changes - for instance). But those few cases are so rare or unlikely as to be pretty much theoretical. You can find more likely cases by reducing what you sign (don't sign the Subject, don't sign the From:, don't sign Reply-To: and so on), but once you start doing that then you're really opening yourself up to replay attacks. (Even if you don't care about replay attacks yourself, they mean that a DKIM signature - or at least one using l= - becomes pretty much meaningless to the None of the mailing lists I'm currently subscribed to could take advantage of l= to preserve a DKIM signature in general (the only ones that append a footer also rewrite the subject to add a mailing list tag or add a Reply-To) - though some of them would support it in the case of replies to email from the list. None of the email I see that has advertising appended to it has had the advertising appended after it has been (or would have been signed). I've no doubt someone can find a real-world example but unless it's reasonably common for l= to be useful- rather than vanishingly rare - it doesn't seem enough to count as a significant benefit, let alone one that's big enough to counterbalance the security holes it opens. If there's a use case I've missed, I'm all ears. Cheers, Steve ___ 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
On Wed, 20 May 2009, Steve Atkins wrote: > Another use case is to use l= to sign a text part of an email, but not > to sign an attachment. In that case I can obviously replace the > attachment with my own content, but depending on the details of the > email structure I may well be able to replace the text section as > rendered to the user as well. Indeed, Outlook will opt to render an HTML part over a text part whenever given the choice. Thus, if you sign only the text/plain portion of a message and an attacker appends a text/html part, the unsigned HTML version will be rendered even if completely different from the text/plain part, and DKIM would give that a thumbs-up. ___ 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
Steve Atkins wrote: > On May 20, 2009, at 2:17 PM, Michael Thomas wrote: > >> Steve Atkins wrote: >>> Why would you want to sign email as something you vouched for, >>> while still enabling anyone to replace the content of the email >>> with something else without invalidating that signature? >> You can't replace it; you can only append to it. > > That's likely wrong, depending on the details of the l= usage. No I'm not. > Firstly, one expressed use case for l= is "l=0" - in other words, don't > sign any of the body. In that case I can put any body content in there > I like, and it'll still be validly signed. That's still appending. > Another use case is to use l= to sign a text part of an email, but not > to sign an attachment. That's still appending. > Another use case is to set l= to the entire length of the email as sent. That's still appending. DKIM only talks about taking responsibility, and only for the parts that are signed. How an evaluator deals with the unsigned parts of a message is outside of the scope of DKIM. > (though the supposed benefit it offers is not clear) You forgot "to me". Mike ___ 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
On May 20, 2009, at 2:17 PM, Michael Thomas wrote: > Steve Atkins wrote: >> Why would you want to sign email as something you vouched for, >> while still enabling anyone to replace the content of the email >> with something else without invalidating that signature? > > You can't replace it; you can only append to it. That's likely wrong, depending on the details of the l= usage. Firstly, one expressed use case for l= is "l=0" - in other words, don't sign any of the body. In that case I can put any body content in there I like, and it'll still be validly signed. Another use case is to use l= to sign a text part of an email, but not to sign an attachment. In that case I can obviously replace the attachment with my own content, but depending on the details of the email structure I may well be able to replace the text section as rendered to the user as well. Another use case is to set l= to the entire length of the email as sent. This case is a little less nonsensical than the others (though the supposed benefit it offers is not clear). I can still append raw content. Depending on the structure of the email I may well be able to have that appended content displayed in place of the original content. This is harder to exploit such that you can entirely replace the original content than the other cases, but given multipart mime and html there's no way I'd say it's impossible. (And, if we're talking phishing attacks, which is one of the supposed risks, then I can put a very effective phishing attack in just the footer of a message anyway - the place people expect to find "Contact Us" or "Log in to your account" or "Secure your access" links). Cheers, Steve ___ 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
Steve Atkins wrote: > On May 20, 2009, at 12:10 PM, Douglas Otis wrote: > >> Since email must deal with large amounts of spam and abuse, it would >> be good to have provisions in DKIM that allow secured attachments to >> be excluded from the DKIM hash algorithm without causing the entire >> message to be considered unsigned > > Why would you want to sign email as something you vouched for, > while still enabling anyone to replace the content of the email > with something else without invalidating that signature? As I recall, the primary argument in favor of l= was survival after being relayed through a Mediator like a mailing list, many of which add a footer to a message. (Proof of concept: This message is an example.) A different way of looking at this goal is that it is an attempt to sign parts of a message body, rather than all of it, much as one might do with s/mime or openpgp. Hence, l= participates in the general desire to have a DKIM signature survive the transfer path. Note that having a signature cover only some of the header fields is another example of this. I think the counter-argument to this goal, with respect to the body, is that header fields other than primary addressing fields and the Subject field are not particularly high-leverage targets for deception, the way the body is. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
Steve Atkins wrote: > Why would you want to sign email as something you vouched for, > while still enabling anyone to replace the content of the email > with something else without invalidating that signature? You can't replace it; you can only append to it. Mike ___ 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
On May 20, 2009, at 12:10 PM, Douglas Otis wrote: > Since email must deal with large amounts of spam and abuse, it would > be good to have provisions in DKIM that allow secured attachments to > be excluded from the DKIM hash algorithm without causing the entire > message to be considered unsigned Why would you want to sign email as something you vouched for, while still enabling anyone to replace the content of the email with something else without invalidating that signature? A low-end, $30 x86 CPU can hash well over 100 megabytes of SHA256 a second, more than enough to saturate an OC-12, so the cost of signing cannot be the reason you want to do so. Cheers, Steve ___ 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
On May 20, 2009, at 9:55 AM, Dave CROCKER wrote: > > Steve Atkins wrote: >> If a signer uses l=0 (or, given MIME games that can be played, any >> other l= value) then the only thing you can say about any validly >> signed message from that sender is that the subject line of the >> message is the same as the subject line of a message that sender >> signed. I don't think that's a useful level of protection for any >> use case. >> >> It means that I can, for example, take one copy of a service notice >> from my bank, leave the headers the same and replace the URLs in >> the body of the message to links to my website, then send it out to >> a hundred thousand people - and it would be validly signed by the >> bank. (The only user-visible content I wouldn't be able to change >> is the subject line). > > This sounds like a plausible and serious scenario. Even with l>0, > it suggests a line of attack -- by adding malicious text that > appears to be part of the bank notice. > > What is the counter-argument, in favor of retaining l= ? IIRC, this concern has been discussed at length. Why rehash the l= feature so soon? > Is there any evidence it is being used? Is there any evidence it is > treated usefully by receivers? Again, it seems too soon to tell. IMPOV, malware scanning email, once considered essential, must not be relied upon to detect threats. :^( Any application attachment should generally contain source authentication signatures. As this happens, DKIM protections become redundant for such application attachments. This redundancy might become significant for large attachments, especially when DKIM adopts more resource intensive hashing algorithms. There are new products and services emerging, along with a growing use of various content protection schemes. The next few years will likely witness an industry evolve as it responds to what is becoming a serious security crisis. People tend to treat email as a means of sharing files. These files are then published and redistributed using various means. This mode of sharing is not ideal, but having application information exchanged in self-authenticating containers would make security much easier to manage. Since email must deal with large amounts of spam and abuse, it would be good to have provisions in DKIM that allow secured attachments to be excluded from the DKIM hash algorithm without causing the entire message to be considered unsigned. Also, it is common to find notices or ads appended to messages. Explicit length indications as to what is signed provides a means to better determine what should and should not be annotated, without the entire message being considered unsigned. It seems prudent to wait. -Doug ___ 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
Steve Atkins wrote: > If a signer uses l=0 (or, given MIME games that can > be played, any other l= value) then the only thing you can say > about any validly signed message from that sender is that > the subject line of the message is the same as the subject line > of a message that sender signed. I don't think that's a useful > level of protection for any use case. > > It means that I can, for example, take one copy of a service notice > from my bank, leave the headers the same and replace the URLs > in the body of the message to links to my website, then send it > out to a hundred thousand people - and it would be validly signed > by the bank. (The only user-visible content I wouldn't be able to > change is the subject line). This sounds like a plausible and serious scenario. Even with l>0, it suggests a line of attack -- by adding malicious text that appears to be part of the bank notice. What is the counter-argument, in favor of retaining l= ? Is there any evidence it is being used? Is there any evidence it is treated usefully by receivers? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
On May 11, 2009, at 3:55 AM, Charles Lindsey wrote: > On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins > > wrote: > >>i: Additional information about the identity of the user or >> agent for which this message was signed >> >> This one is more controversial. It adds an awful lot of complexity >> and confusion about the semantics of what a signature is and quite >> a few people (myself included) would prefer it went away. But there >> are some potential uses for it, and some are already invested in >> it, so it seems unlikely we'd reach any consensus to drop it. > > At the moment, this tag plays no part in the protocol (except that > it needs to be correctly signed). It has caused confusion, which our > recent errata have sought to dispel. Now there is the opportunity to > sit down and define some proper rules for its use, if we are so > minded (e.g. in mailing lists). Essentially, it could be useful for > signatures which are NOT by the Author Domain. Disagree. This tag plays an important role in the protocol! This tag permits differentiation of intra-domain sources to mitigate replay abuse, and is supported by RFC 5451 to aid MUA annotations. Any attempt to use the i= value for email-addresses where the signing domain is not authoritative will create incompatibilities. Different domains can authorize a DKIM signing domain within a single transaction. A convention using a specific dedicated sub-domain, such as "_authorized", within the i= value could even indicate an expectation of the signing domain being authorized by the From email- address domain. Perhaps this could be done with base-64 encoded hash labels placed within the From email-address domain. This would be a fairly low overhead (about that of CNAMES), and allow any number of domains to be authorized. For example: ._dkim_authorized.other-example-domain.com TXT "example.com" From: jon@other-example-domain.com DKIM-Signature: i=radius_12...@_authorized.example.com; d=example.com -Doug ___ 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
On Mon, 11 May 2009, J.D. Falk wrote: > +1 to dropping these, though I'm willing to be convinced otherwise if > there are verifiers actively using them to make policy decisions -- > particularly z=. I can't imagine using "z=" as an input to a policy decision. I've only found it useful when debugging at specific sites. ___ 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
Steve Atkins wrote: > Summary of features to keep +1 to keeping these. > Summary of features to consider dropping +1 to dropping these, though I'm willing to be convinced otherwise if there are verifiers actively using them to make policy decisions -- particularly z=. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ 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
On Mon, 11 May 2009, John Levine wrote: > Any idea what they're doing with it? Having added some support for DKIM > to majordomo2, I am more convinced than ever that the motivation for l=, > list recipients will filter list mail using the contributor's signature > rather than the list signature, is just wrong. I'll ask the person who submitted the patches, and also ask if anyone else is using them. > If I may pile on, let me reiterate Dave's point about q=. In the > unlikely event that we invent another way to look for key records, > that's the time to design the syntax to specify it. Yep, I agree. ___ 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
On May 11, 2009, at 8:29 AM, Eliot Lear wrote: > On 5/11/09 5:09 PM, Steve Atkins wrote: >> On May 11, 2009, at 3:55 AM, Charles Lindsey wrote: >> >> >> I could conceivably see this being an issue on an acm.org style >> forwarder, >> if there were one that modified the content it forwarded, but not a >> normal >> mailing list. I don't think that's a iikely use case, though. >> > > Sorry- I'm not quite sure what you're saying here. That an ACM.ORG- > like forwarding address is likely or that they would tag something > to the bottom of a message? I think it unlikely that they would modify the message, while not taking any responsibility for the message content. A simple .forward style forwarder is fine, as it doesn't modify the content. A forwarder that does modify the content in any way will invalidate DKIM signatures that do not use l= [1]. Because of that it will need to take that into account operationally, probably by signing with it's own signature on outbound and maybe validating signatures on inbound mail[2]. Whatever it does to handle forwarding of non-l=-using DKIM signed email correctly will also that it also forwards l=-using DKIM signed mail correctly, meaning l= adds no obvious value there. Cheers, Steve [1] it'll likely invalidate ones that do use l= too, but that's not important here. [2] One of the more plausible use cases for the Authentication-Results header, where the header shows the results of inbound DKIM validation and is signed by the forwarders signature on outbound mail. ___ 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
On 5/11/09 5:09 PM, Steve Atkins wrote: > On May 11, 2009, at 3:55 AM, Charles Lindsey wrote: > > >> On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins> >>> >> wrote: >> >> >>> l: Body length count >>> >>> This opens up a whole host of security issues, related to being able >>> to change the rendered content of the message entirely after signing >>> without breaking the signature. Removing it would remove a security >>> hole you can drive a bus through. Is it being used? Are there any >>> situations where it has proved useful? >>> >> Signing the body is not essential for the primary purpose of DKIM, >> which >> is to expose phishers and the like. Malicious modification of a >> message >> _after_ is has been posted is relatively rare. >> > If a signer uses l=0 (or, given MIME games that can > be played, any other l= value) then the only thing you can say > about any validly signed message from that sender is that > the subject line of the message is the same as the subject line > of a message that sender signed. I don't think that's a useful > level of protection for any use case. > > It means that I can, for example, take one copy of a service notice > from my bank, leave the headers the same and replace the URLs > in the body of the message to links to my website, then send it > out to a hundred thousand people - and it would be validly signed > by the bank. (The only user-visible content I wouldn't be able to > change is the subject line). > > If there is ever any user-visible sign in an MUA that an email was > DKIM signed, or benefits to delivery for email being DKIM signed by > a trusted signer, *and* some trusted signer actually uses l=0, I'll bet > you'll start to see a lot more malicious modification and retransmission > of messages. > > >> So writing l=0 gives a way >> to sign the headers only (saving quite a bit of overhead if that is >> useful, plus removing all problems arising from changes of encoding >> and >> other mungings during transit. >> > > > I could conceivably see this being an issue on an acm.org style > forwarder, > if there were one that modified the content it forwarded, but not a > normal > mailing list. I don't think that's a iikely use case, though. > Sorry- I'm not quite sure what you're saying here. That an ACM.ORG-like forwarding address is likely or that they would tag something to the bottom of a message? Eliot ___ 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
On May 11, 2009, at 3:55 AM, Charles Lindsey wrote: > On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins > > wrote: > >> >> l: Body length count >> >> This opens up a whole host of security issues, related to being able >> to change the rendered content of the message entirely after signing >> without breaking the signature. Removing it would remove a security >> hole you can drive a bus through. Is it being used? Are there any >> situations where it has proved useful? > > Signing the body is not essential for the primary purpose of DKIM, > which > is to expose phishers and the like. Malicious modification of a > message > _after_ is has been posted is relatively rare. If a signer uses l=0 (or, given MIME games that can be played, any other l= value) then the only thing you can say about any validly signed message from that sender is that the subject line of the message is the same as the subject line of a message that sender signed. I don't think that's a useful level of protection for any use case. It means that I can, for example, take one copy of a service notice from my bank, leave the headers the same and replace the URLs in the body of the message to links to my website, then send it out to a hundred thousand people - and it would be validly signed by the bank. (The only user-visible content I wouldn't be able to change is the subject line). If there is ever any user-visible sign in an MUA that an email was DKIM signed, or benefits to delivery for email being DKIM signed by a trusted signer, *and* some trusted signer actually uses l=0, I'll bet you'll start to see a lot more malicious modification and retransmission of messages. > So writing l=0 gives a way > to sign the headers only (saving quite a bit of overhead if that is > useful, plus removing all problems arising from changes of encoding > and > other mungings during transit. > Moreover, there are too many agents arounf > that insist on adding boilerplate to the end of messages (look what > the > mailing list expander for this list does, for example). Putting a > proper > l= value circumvents that problem (which is why it was out there in > the > first place). That assumes that the important signature in that case is the original authors, not the mailing lists, and that the mailing list itself isn't trusted. I think the normal model of a mailing list is not a simple mail forwarder, rather an agent that receives and validates mail then sends mail out to subscribers under the mailing lists signature. I could conceivably see this being an issue on an acm.org style forwarder, if there were one that modified the content it forwarded, but not a normal mailing list. I don't think that's a iikely use case, though. Cheers, Steve ___ 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
>> l: Body length count ... >Signing the body is not essential for the primary purpose of DKIM, which >is to expose phishers and the like. Malicious modification of a message >_after_ is has been posted is relatively rare. Aw, come on. If the Bank of X were to send out mail with only the headers signed, how many milliseconds do you think it would take before bad guys replaced the URLs with fake ones and spammed it out? R's, John ___ 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
On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins wrote: > i: Additional information about the identity of the user or agent > for which this message was signed > > This one is more controversial. It adds an awful lot of complexity and > confusion about the semantics of what a signature is and quite a few > people (myself included) would prefer it went away. But there are some > potential uses for it, and some are already invested in it, so it > seems unlikely we'd reach any consensus to drop it. At the moment, this tag plays no part in the protocol (except that it needs to be correctly signed). It has caused confusion, which our recent errate have sought to dispel. Now there is the opportunity to sit down and define some proper rules for its use, if we are so minded (e.g. in mailing lists). Essentially, it could be useful for signatures which are NOT by the Author Domain. > > l: Body length count > > This opens up a whole host of security issues, related to being able > to change the rendered content of the message entirely after signing > without breaking the signature. Removing it would remove a security > hole you can drive a bus through. Is it being used? Are there any > situations where it has proved useful? Signing the body is not essential for the primary purpose of DKIM, which is to expose phishers and the like. Malicious modification of a message _after_ is has been posted is relatively rare. So writing l=0 gives a way to sign the headers only (saving quite a bit of overhead if that is useful, plus removing all problems arising from changes of encoding and other mungings during transit. Moreover, there are too many agents arounf that insist on adding boilerplate to the end of messages (look what the mailing list expander for this list does, for example). Putting a proper l= value circumvents that problem (which is why it was out there in the first place). -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
>> l: Body length count >Despite the warnings we've posted about it, at least one site has >contributed patches to our implementation that extends its basic utility. >That means there's at least a little demand for its use. Any idea what they're doing with it? Having added some support for DKIM to majordomo2, I am more convinced than ever that the motivation for l=, list recipients will filter list mail using the contributor's signature rather than the list signature, is just wrong. If I may pile on, let me reiterate Dave's point about q=. In the unlikely event that we invent another way to look for key records, that's the time to design the syntax to specify it. R's, John ___ 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
Murray S. Kucherawy wrote: > I'd rather leave an unused > but potentially useful hook in there versus removing it now only to have > it added back in later, possibly poorly. Murray, this is an absolutely basic bit of philosophy in protocol design. It drives lots of decisions. Unfortunately, historically, this is exactly the logic that adds useless bloat to protocols and causes interoperability problems. When a feature is not currently used, it tends to be badly implemented, since it isn't exercised. By adding it later, you are ensuring that there is a real need and, therefore, real end-to-end testing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Features that could be reconsidered as part of the bis process
On Sat, 9 May 2009, Steve Atkins wrote: > q: List of query methods > > I don't think q= is going to be controversial either, but I'm > mentioning it separately as it currently only has one value, the > default, it's unlikely to be extended, and if it were it would require > a whole new RFC to do (which rather than extending the q= header, > could add a "new" q= header). It doesn't hurt to keep it, though, as > it's so simple. If we drop it, it would just get added back in later when some other key publication mechanism is needed. That said, I'd rather leave an unused but potentially useful hook in there versus removing it now only to have it added back in later, possibly poorly. > l: Body length count > > This opens up a whole host of security issues, related to being able > to change the rendered content of the message entirely after signing > without breaking the signature. Removing it would remove a security > hole you can drive a bus through. Is it being used? Are there any > situations where it has proved useful? Despite the warnings we've posted about it, at least one site has contributed patches to our implementation that extends its basic utility. That means there's at least a little demand for its use. > z: Copied header fields > > Has this been useful? Is it likely to remain useful beyond a testing > phase? Yes, it has proven useful in debugging specific installations, not simply specific implementations. -1 on removing it. > Is anyone supporting t=y in a DKIM validator? What does it do in terms > of delivery and communication with the sender that's different to > normal non-test usage? And is it useful? Yes, we do. If a message fails and a customer has actually (against our defaults and recommendations) configured the filter to reject mail that fails signature validation, the "t=y" key drops the "fail" result to a "neutral" one and avoids rejection. I don't know if that's actually useful behaviour (our user base has been slack when it comes to replying to such inquiries), but yes, we do have specific code that pays attention to it. But I'm less insistent about this one than I am of "z=". ___ 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
Mark Delany wrote: >>> DKIM-Signature Header tags >>> >>> x: Signature expiration >>> l: Body length count >> Removal of these would be a show stopper for me. In fact, overall, >> anything that is SECURITY related should be protected from removal >> proposal. > > Do you mean anything that is security related or do you mean any thing > that improves security? You're not being very precise. Mark you know what I mean. Overall, I would be -1 for removing any current feature designed to improve security, control aspects of the message that are related to the validity of it. > As I understand it l: reduces security because it introduces wiggle- > room True. Maybe I was thinking l is the original pre-cl4n byte count of the message, not the signed count, so anything over the original should be considered invalid. > and x: seems only to offer theoretical benefits that are far more > concretely established via key revocation in the DNS. Thats one thought. But if you are not going to be revocation keys, you still might want to have a time limit. You are making the assumption that people will be revoking keys for the purpose to expire messages. Its a good policy, but IMO after a while that is going to get tiresome for many when all they wanted to do is put an x= on the message. Its like passwords, it would be nice if users change their password regularly, but their don't so many systems force it with password expirations. Consider also it is does the verifier a favor too. Whether or not x= matches the key expiration period, the verifier can save lookup overhead for those messages that expired. Overall, I don't see these as candidates for complexity. These are simple low overhead checks, especially x= because if the message expired there is no need hashing overhead - immediate reject. Anyway, thanks for your feedback. -- Sincerely Hector Santos http://www.santronics.com ___ 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
>> DKIM-Signature Header tags >> >> x: Signature expiration >> l: Body length count > > Removal of these would be a show stopper for me. In fact, overall, > anything that is SECURITY related should be protected from removal > proposal. Do you mean anything that is security related or do you mean any thing that improves security? You're not being very precise. As I understand it l: reduces security because it introduces wiggle- room and x: seems only to offer theoretical benefits that are far more concretely established via key revocation in the DNS. Furthermore, x: is largely meaningless if you accept that DKIM is a temporal authentication mechanism, which it has always intended to be. Mark. ___ 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
Good starting point list. Steve Atkins wrote: > Summary of features to consider dropping > > >DKIM-Signature Header tags > > x: Signature expiration > l: Body length count Removal of these would be a show stopper for me. In fact, overall, anything that is SECURITY related should be protected from removal proposal. >TXT RR tags > > t=y: Domain is testing DKIM +1 Definitely this because that was suggested many moons ago - nothing can be in perpetual testing and should not be used as an excuse for failure. > t=s: Require that domain in i= and d= are the same Until POLICY is resolved, I do not suggest removing this. > Other changes to consider > = > > Drop support for SHA1 entirely. The only technical reason to keep this is that SHA256 is not guaranteed to be supported on all Windows station which would be a concern for Window ISVs. However, that was more problematic in the past because Microsoft made SHA256 and "added value feature" for their Security layer i.e. you had to update Windows to Vista. But they have been made aware that SHA256 should be part of the OS security layer and via service packs have provided in Windows OS. So its less of an issue today to use SHA256 exclusively. Should SHA1 be dropped? I personally wouldn't vote to remove it. > == > Discussion of other changes to consider > === > > Drop support for SHA1 entirely. It's beginning to look > cryptographically very dubious, and is being dropped by pretty much > everyone else. Even if the attacks against it don't affect the way > it's used in DKIM it seems unwise to suggest it be used at all. At the > very least it seems a poor "marketing" move to include an algorithm > that's been dropped by most everyone else as insecure before this spec > is finalized. I don't think this is valid reason for dropping SHA1. First, there is an overhead penalty using SHA256, second, as indicated above, although MS did update their OS to include SHA256 support, from a verificattion standpoint, you are shooting at darts (will the client support the signature hashing?) and it might be a technical solid idea to have a common denominator available in the short term for implementations. Keep in mind that not everyone using OPENSSL, so unless OPENSSL is made part of the Required DKIM Resources, you can't enforce an method that simply may not be available on the Windows CLIENT machine. > "Verifiers MUST support rsa-sha256 and MAY support rsa-sha1. Huh? The verifier will be driven by whatever the signature has and is capable of supporting. The idea that there might be half-baked DKIM verifiers is a bad taste for encouraging DKIM signers. > Signers SHOULD sign using rsa-sha256 and SHOULD NOT sign using rsa- > sha1." might provide enough wiggle room to allow existing code time to > migrate away from SHA1. There should be no MATCHING issue born from any of the this. DKIM signer and verifiers both must play by the same signing rules. I understand this is an issue. And it might be ok to stick with SHA256, but I personally do not see this as a barrier to adoption. What we should be looking at is WHY, hardly anyone, but only a few systems are using DKIM. I seriously doubt it is the hashing method or the expiration or any of the other suggested tags to drop. The reasons I have not added DKIM into our commercial software is: - Lack of a visible payoff. - Lack of policy, what I call the DKIM Domain Ownership Problem - Cost of implementation (revamping of existing software) I personally believe we should not be doing BIS with the idea of REMOVING major parts of it. Today, we live in an integrated world, it is not the 1980s where each protocol must be isolated fully. No, it is 2009 and the protocol needs to have integration ideas - WHY is someone going to bother to sign, why is someone going to verifier, and quite frankly, we have handicapped the both the signer and verifier with poor POLICY and DOMAIN Ownership engineering management for the past 3-4 years. There is simply no strong incentive to implement DKIM. Streamlining it ala ADSP isn't going to improve adoption rate. This is a Total, Big Picture problem. -- Sincerely Hector Santos http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
