Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
Just trying to connect the dots. SM wrote: Hi Hector, At 11:18 01-04-2011, Hector Santos wrote: Off hand, and I have to go back, I believe seeing some systems using Authetication-Results to always include a i= as part of its A-R header result whether it was defined or not and when not, a default value is displayed. For example, this is the A-R result for my signature into this IETF-DKIM list: Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@isdg.net [snip] Does that mean, a proposal to remove i= in DKIM-BASE, would imply an update to the A-R draft is necessary? RFC 5451 is a proposed standard. It is not a product of the DKIM WG. It's up to the author of that RFC to see whether an update is necessary. Regards, -sm -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line
J.D. Falk wrote:
On Mar 31, 2011, at 8:51 AM, Al Iverson wrote:
I think the MLM document makes all of this stuff pretty clear already.
It does to me; it seems like dropping the original signature and
signing with the list manager site signature is the appropriate way to
go.
Yup. The problem isn't that we haven't made this advice public (though
it may carry more weight after last call.) The problem is that it takes a
long time for these ideas to disseminate to all list software deployed
everywhere -- especially the outdated versions of MailMan that many sites
run on autopilot.
FWIW, here's how I got DKIM signatures on messages resent by the lists
I host with MailMan two years ago, without needing to wait for MailMan
to update anything at all:
http://www.circleid.com/posts/dkim_for_discussion_lists/
This is cool J.D.
The DKIM integration for our MLS was very simple and the outline I
provided in DSAP (ideas covered in MLM as well) was written with the
idea for a minimal software design, no failure points promoted by the
changes and simply plug and play with existing software. It had only
two MLS change considerations:
- Restrict POLICY restricted domains as part of the list subscription
process. At the time DSAP was written, this meant disallow
subscription
for a domain using an exclusive signing practice which included a
3rd party signing restriction. If the policy allowed 3rd party
signers
to exist, then the user was allowed to join the list.
- If mail changes will be done, strip old signatures and resign the
message before redistribution.
We finally added this logic last year and the only MLS change was to
add the subscription logic because we designed the framework for
signing is done on the outbound MTA server.
The big change item I originally expected would need to be done in the
MLS adding new DKIM signing options per list turned out to be
unnecessary. We avoided this big software by using the common list
template file used to add additional headers such as all the LIST-*
headers. I used a META header to trigger when a list should be signed.
For example, the template file has:
List-Id: {LT} {LN}.{LD}
List-Post: mailto:{LE}
List-Unsubscribe: mailto:{LN}-unsubscribe@{LD}
List-Subscribe: mailto:{LN}-subscribe@{LD}
List-Help: mailto:{CN}@{LD}?body=help
WCLS-Signthis: {LD}
So the MLS will do its normal thing of preparing a list distribution,
adding the list-* headers carrying the meta header WLCS-SIGNTHIS:
expanded with the list domain. When the outbound MTA gets this
internal feed, it looks for this meta header, extracts the
list-domain, checks another setup file to signing options for the
list-domain, if any. If found, any header striping options are
followed and the list message message is signed.
So I guess the point is that you can make a MLS DKIM aware by using
meta headers to current setup files and using that information as feed
for edge software.
-
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] Work group future
for non list mail worked fine for me for a period of time and then I started regularly getting DKIM=FAIL in the smtptrace log so I have not looked at again for some months. - Customer comment on using our new DKIM implementation Do we really want DKIM to get into a common situation where lacking a protective layer for domain DKIM signed mail becomes ignored as wasted overhead and bandwidth? I hope not. I perfectly understand the DKIM-REPUTATION model promotes the idea that only VALID mail (Good Mail, white listing model) should be considered when its signed by a trusted source. Everything else is basically undefined by DKIM. Fine, I won't debate the GOOD MAIL Trusted Source model. The job was well done by the WG promoters of this model. VBR seems to be promising as an open protocol. But maybe the POLICY promoters can be given a chance to address a layer that helps protect the unsecured abusive undefined block ignored by REPUTATION. Thanks -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-03
Dave CROCKER wrote: Not only is it confusing, it's wrong. Wildcard records work just fine when the wildcard is below the _domainkey label, e.g. *.foo._domainkey.example. They work less fine in other cases. The modified text I offered is intended to handle several coverage problems with the original text, including the one you cite. Are you suggesting that it does not succeed? If so, what text do you instead suggest? Dave, I believe the text needs to include guidelines not just for DKIM clients but for DNS software manager authors or administrators. This issue started (by me) because a ISP vendor (one of the largest) that did not offer a clear way in their web based DNS Manager for their customers to add explicit DKIM TXT records and the method offered lumped TXT records subdomains with wild cards.As a result, the order was such that SPF records were returned as well. So its not just about the DKIM clients being aware of multiple TXT segments. The spec audience will probably include HOSTING sites people that will look into how DKIM records is implemented and offered to this customers. I think text as simple as follows should be considered (note, I am just providing a starter, not saying these are the exact words) DNS hosting administrator and developers should offer the ability to add DKIM records that will not conflict with another other DNS (TXT?) query protocols and is not part of the wild card results. PS: As I recall, the issue for the customer was resolved with the vendor after the support incident was raised beyond the normal help desk level. Keeping the same interface, a new undocumented input format syntax was provided for adding the TXT subdomain record that was not part of the wild card results. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Are arbitrary From addresses in the physical world following DKIM?
Mark Delany wrote: Forgive me for a bit of an aside, sortof. A lot of people have long used the Postal Service analogy of being able to supply an arbitrary return address as a justification for doing the same in email (DC I'm looking at you, buddy). So did anyone catch the news today that UPS.com are planning to verify the return address of a package against your drivers license? And that other postal services may soon follow suit? In other words, the days of providing an unauthenticated author address may be numbered in the physical world. It's all in the name of security theater of course, but nonetheless, somewhat amusing in the DKIM context. Mark. Hi, At least for us, the return path concept has the basis for our WCSAP (Wildcat! Sender Authentication Protocol) SMTP Level Filter. Since 2003 it has been a persistent and huge chuck of our total SMTP level filters around %60 for the CBV (Callback Verification). Logs are generated every night, http://www.winserver.com/SpamStats RFC 2821/5321 does provide an opening for validating the return path in section 3.3: 3.3 Mail Transactions . Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. What we did was delay any checking for MAIL FROM: until the RCPT TO: is valid because we also found a HUGE failure with RCPT TO also around %60+. This was important to reduce all the DNS lookup with WCSAP when it validates the return path. So no checking is done until a RCPT TO: is valid. Other SPF sysops have carried on this delay SPF verification concept and I also got comments from Barricada people that it was a good idea to do this, especially the anti-relay checking where a random bad address is checked to see if the remote will accept always. That said, I don't advocate wide spread usage for a CBV (Call Back Verification) but the fact remains most of the time they are BAD from bad guys. Also, I don't think an EXTENSION for SMTP to do a proper CBV will work because the beauty of the current logic is that it addresses the legacy spoofers. Anything new will only address the NEW PEOPLE doing it wrong, it will not address the legacy SMTP clients and that is what CBV addresses. As it related to DKIM, well, it just goes to show it really has nothing to do with DKIM because it is a RFC 5322 technology. i.e. for us, DKIM will never trump SMTP level filtering by other means. At best, skip smtp checking, and do it at the DATA level or post SMTP acceptance, requires that the SMTP receiver stamp the spooled file with a Return-Path which was not always the case, but it is increasingly the case IMV. Any hoo, I do believe that when a sender does issue the MAIL FROM: it should be 100% correct at that point in time, not later because the SMTP assumption is that it is correct for the purposes of a BOUNCE potential. But I have heard arguments the the validity of the return path is only when the bounce is necessary. I don't agree with that. IMV, at the precise SMTP moment it is issued at MAIL FROM:, it *MUST* be valid at the time point. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Japan has been set up
Tsuneki Ohnishi wrote: So, my point is that what do you think of the idea to have an new entry in ADSP discard-if-no-sig, which allows senders to declare messages without DKIM signature should be discarded? If that's possible, it makes our job a lot easier and faster. Hi. You are basically asking to make a distinct difference between: 1) a real no signature message versus 2) a message who's signature is broken (invalid). The DKIM specification says that a broken signature is the same as no signature message. It is important to know the difference because if you are concern about a Real No-Sig versus a Broken one where a Real No-SIG is discarded but a Broken one is not, then whats to stop the Bad Guy from adding a broken signature by design and for the sole purpose of making sure the message is now indeterminate and you don't filter it? The problem with DKIM is the is the stuff in the middle - A real no-sig message can be made to work, as well as when there is a valid signature. It the faults of the system that is challenging - what do you do with failures and what makes it even more difficult is the specifications has evolved to one where where any system, middle-ware or hop, can break or remove an author domain signature without restrictions. This was done to appease the LIST managers, 3rd party signer and the reputation market. IMO, I think DISCARD should cover what you want, but you have to view it as a strong policy with no exceptions, i.e., a broken signature is just as bad as no-signature and more importantly, no interference or 3rd party signers can override the message author domain security expectations. If you allow for broken signatures to be acceptable partially or otherwise in an ADSP setup, then it just confuses the intent and it potentially feeds bad guys to give you broken signatures because that is OK by you. Right now, there is no incentive for bad guys to adapt or change. They can remain in legacy operations (no signature) because there is no wide adoption or foundation for DKIM policies or the handling of policy faults. Having a MUST SIGN policy widely adopted (and supported) would begin to make a change in legacy operations. They will most likely avoid your POLICY protected domain. But if you allow for broken ones, then they can adapt by adding a spoofed but broken signature. -- Hector Santos, CTO http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
Barry Leiba wrote: Who is responsible for dealing with this situation? If the DKIM spec is at least partially responsible, to what extent, and what should it say? Whether we have the guts to do what is correct as oppose of trying to work it in due to IETF meeting mile stones and time deadlines, is entirely different issue. IMO, DKIM is responsible for the input that are part of is formula. Parts it MUST make sure are RFC5322 correct for consumption with its purported trust signature, especially its sole single input header requirement, 5322.From. Proposal: 1. The DKIM spec is responsible for describing the problem in terms of how it relates to signed and unsigned versions of the fields. That's the stuff in 8.14. Who's version? 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. +1 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. +1 4. We should agree to this or some variant of it, and then move on. This is not meant to satisfy everyone. In fact, it isn't what I'd prefer, if I had my full choice. But it takes care of the problem in a way that I think is sufficient, and allows us to resolve the issue. +1 I believe I provided good text with the original ISSUE posting I made and also modifications along the threads. This focus mainly with following up with the logic for the last header begins in Section 5.4 and where the corrective text should be made. Its a do this , but keep in mind that semantic. Overall I prefer to see an updated specification that will help developers write software consider options to deal with this correctness issue directly and independently from another protocol logic. IMO, this is the proper Software Engineering approach to maximize a fix across all MTA of all kinds. I prefer not to read text that tries to pass the buck, push the burden on to MTAs or MUAs solely. That will minimize the adoption rate because they could be legitimate MTAs that are not capable to satisfy the outside RFC5322 correctness requirement or mandate in order for DKIM to provide workable results. At the end of the day, I believe that it is major goal to get ALL DKIM software to work with the same expectation here and not get into situations in the future where there are deviations. It MUST become a mandate in order to build the initial trust required for DKIM. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
Alessandro Vesely wrote: 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. +1. Enforcing some RFC conformance is a task that many MTAs can (optionally) do natively. But DKIM can not make that presumption that is the prevailing nature of many MTAs. At best, it can RECOMMEND that integration DKIM into a mail system that for BEST results, a general filter would address this issue. But it can't assume that will be possible as it might mean a software change. Hence the better DKIM software will offer a direct solution that COULD be turned off when the MTA is capable of doing the filter itself. For example, OpenDKIM is a package mainly for the Sendmail MTA. It may have or will have a MTA milter to check for RFC 5322 compliance. However, the I believe the software also allows has a DKIM only component that can be used in other MTAs. You don't know if these other MTAs will have the same kind of filter DKIM is expecting in order to have clean results. Now take Alt-N pure C/C++ DKIM API with no tie-ins to any MTA. It has an non-overhead DKIM verifier option that deals this multiple 5322.From issue directly and independently from any other layered requirement. To me, the latter is the best approach for the specification to take. Allow Readers of this document to decide how they will implement DKIM based on the MTA they are using or MTAs they are targeting. Perhaps this is an issue about MTA configuration, rather than specifically for the signing module. Which is just as equal of saying MTAs may or may having RFC5322 compliance checking. DKIM can not be dependent for providing valid results only when working with MTA that have RFC5322 compliance checking. For example, I'm quite happy that such tweaking occurs before signing, so that the signer signs the revised version. Tampering with mail is not justified here. Either the mail is good to sign or bad to sign when it comes to DKIM signing. 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. This is again a question of roles. John has (correctly) recommended that verifiers don't tamper with the message content, except for possibly adding an A-R field. However, a DKIM verifier does not /have/ to act as a verifier only. An additional role is the umbrella under which a filter module may discard suspicious messages, suppress unsigned singleton fields that occur more than once, or anything it deems cool. Generally, the caller of the DKIM procedure would act on its results. I prefer to see a blackbox model for DKIM where its interface points are well defined. Its input was well described with stated boundary conditions and its output is well defined and described with a view on being a feed for possible message filters/handlers. -- Sincerely Hector Santos http://www.santronics.com -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack, why RFC 5322 compliance is a fuzzy term, and what about malformed MIME str
Murray S. Kucherawy wrote: It boggles my mind that a specification called DomainKeys Identified _MAIL_ has to be explicit about the fact that the input is expected to be formatted like a mail message, and that there's even pressure to say in a normative way that someone implementing this has to make sure that's the case. Security Considerations of RFC5451 was updated to include language about hardening against input deliberately crafted to try to confuse or crash applications, and I was surprised that they (secdir) felt that was necessary; I expected that to be fairly obvious to anyone in the audience of a standards track RFC. (It wasn't required to be normative, however.) In my view of the IETF RFC documents, its a matter of technical writing style. They are neither a 100% Functional Specification nor 100% Technical Specification, but a blend to help reach a wider audience of disciplines. A good amount of expertise and/or experience is required to get the message across and it also requires a good amount of expertise/experience to be able to read the message to both a) extract and b) extend the engineering insights required to produce the protocol. In this case, in my technical opinion, Section 5.4 has incomplete implementation insights regarding the single field requirements for RFC 5322. It is an insight that would of been included if we had seen the issue when it was first written four years ago, especially when we went through the TA process. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The Total Solution is an Integrated One.
Charles Lindsey wrote: On Thu, 04 Nov 2010 02:04:16 -, Hector Santos hsan...@isdg.net wrote: It is (A) that is most important here and this is where the corrective text should be added. The original ISSUE Posting included proposed text to follow the last header paragraph in Section 5.4: Special Consideration for Verifying and Signing From: Header As an exception, header hash verification MUST be done for all 5322.From fields and not just the last one. Signing MUST be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. This will mitigate any replay that prepends a new 5322.From header to a DKIM signature valid message. Some MUAs have shown to display only the first 5322.From header found. + 1/2 You seem to imply that hash verification MUST be done for all From fields both during signing AND verification. Fine! You say exactly what is to be done when signing, but leave it unclear what to do if a verifier hashes all the From:s it can find, but finds there are insufficient of them listed in the 'h=' tag. So I suggest you add the following: Verification MUST check that all 5322.From fields found have been included in the signature. This will mitigate any deliberate omission to sign some 5322.From (such as the first, which might be the only one displayed by some MUA) by a malicious signer. +1. I guess I as a bit bias because the DKIM API I was using had already resolve this issue with an option: Allow Unsigned From Headers which was an extra option and by default is zero (OFF, FALSE, DISABLED) hence each 5322.From header found were checked against the h= list of tag values. Think of how a verifier migh parse this stuff. While there could be different methods, a typical model is a streaming line parser: while ReadNextLine(line) do DKIM_VerifyLine(Line) wend As it reads the headers line by line, it checks the h= tags to do the hashing. The method used in this DKIM API is to remove the h= tag value as it matched and rehashed the header as it rebuilding the signature hash. So when it found the first 5322.From, it checked, hashed and removed the from tag from the list of tags in h=. If another 5322.From was streamed in, the special IF statement for Allow Unsigned From Headers checked to make sure there was still a h=from tag for it. If not, an invalid signature result was immediately returned. Think of this option as a plug and play extra requirement which allowed an operator to revert to the original 4871 described behavior if the option was enabled. When enabled, the presence of a 2nd 5322.From did not violate the 4871 Section 5.4 logic. My text was basically trying to keep with the idea that its (erroneously) possible to have an extra 5322.From header but the DKIM protocol extra requirement would enforce only one to be hashed. So by saying header hash verification MUST be done for all 5322.From fields and not just the last one, it will help keep with the current logic in Section 5.4 but also help create the invalid signature we are looking for from a plug and play aspect. And furthermore, I would suggest replacing 5322.From fields by once-only fields (where once-only is defined as some explicit list of headers derived from RFCs 5322, 4045 and maybe others - precise contents to be discussed separately). True. I'm on the fence with that though to the extent here required as I think the main focus should be with the security issue here which is mostly with 5322.from since it is the only required DKIM binding for headers and arguably the #1 Display Header to be concern about. But sure, even if generic text is used here, it should probably have an i.e, or e.g, for 5322.from to make sure the prime focus is the main security reason for these extra considerations. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] The Total Solution is an Integrated One.
provided depending on what the other integrated parts can do or not do. The total solution is an integrated one and since this belated highlighted ISSUE has now shown it is also a problem for non-DKIM streams, integrators are now smarter about the issue and will most systems will begin to do more RFC5322 checking prior to any DKIM processing or display to users. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
. Overall, we should emphasize that all DKIM verifiers SHOULD perform this check or offer an option to check for this specific double 5322.From violation to address integration models where it is not possible for MTA receivers to perform this checking. The above is all I would need as a software person to weigh all design and integration decisions and/or what to make available to operators. For us, we learned that we can best address this a SMTPFILTER-CHECK-RFC5322 filter at our MTA receiver for all inbound messages. Like Murray, I believe this is prudent and the best approach. But unlike Murray, from a generalize protocol standpoint adding DKIM to a product line, I know I can not enforce this method with all MTA systems which may not have the capability or level of software options to do this checking at a MTA. So the DKIM verifier and signer protocol components or API SHOULD also provide a mitigating solution when specific MTA integration models does not provide an answer. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Absolving Domain Responsibility
John R. Levine wrote: Putting on my native speaker of American dialect hat, I don't see a useful difference between responsibility and some responsibility in this context. In practice they mean the same thing, and neither means total responsibility. Agreed. If someone goes to the effort of signing a message and publishing a validation key, they have taken some responsibility for the message. On the other hand, if you then complain to them about it, and they tell you to get stuffed, that's the end of it. (You might stop accepting their mail, but that's outside the scope of DKIM.) It's some responsibility, but it may not be very much. So pick one and be done with it. It doesn't matter which one. The issue is that its too vague and incomplete especially when there is an unknown and unrestricted RE-signers involved as part of the framework. What does responsibility actually mean? Does it mean that the last signer is the blame or part of the blame for any harm caused? Does the last signer absolve all previous signer(s) responsibility? Is this something the original domain signer is aware of? INFORMATIVE NOTE: DKIM allows resigners to operate. When a resigning takes place, all previous signer domains no longer have a responsibility for the message. Of course, in a perfect integrated protocol world, one could add statements about POLICY restrictions, but that would be a taboo here at this point. Maybe it can be stated another way to provide the concept of absolving domain responsibility. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Some responsibility
Murray S. Kucherawy wrote: Graham Murray claims to do the opposite. What it does provide is assurance of acceptance of liability for messages which are signed. ie if a message is DKIM signed, the signer cannot later claim It was nothing to do with me, it must have been a forgery +1 Moreover, I think we tread on dangerous ground when we make assertions in any direction that are legal rather than technical. Yet there is exist an assertion of an ambiguous legal term that raise more questions than not about the potential risk factors for a signing service or organization can assume with a blind responsibility for the signing of a domain for any message. We're about as expert in law as we are in MUAs, which is to say not at all. Speak for yourself. There are those with commercial product development, legal and liability understanding to have very keen realistic view of the concept and a quick grasp for have a legitimate concern for the responsibility term in DKIM. It is a closer reality than what you are expressing. DKIM is an unprotected protocol and it is NO position to suggest to anyone that it can assume a responsibility that can easily by violated. As you ready to take BLAME for a poor signing of a faulty message that can predictably harm an END-USER based on added DKIM-based confidence by yet another 3rd party? I don't think so. We have MUAs in the market place and for nearly 30 years. Do You? Mind you, one doesn't really need to have direct MUA design experiences to gain good insight and understanding and input. Gods know, you think you now more than others regardless your silly statement. But the fact remains, whether you care or not, there are some here that do have real MUA product design experiences. Have a good day -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Some responsibility
Rolf E. Sonneveld wrote: Hi, unfortunately I didn't have the time to do a full review of 4871bis, but there's one thing I'd like to draw attention to. In the original text of RFC4871 DKIM was described as: DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. In draft 2 of RFC4871bis DKIM is described as: DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. I'm not very happy with the introduction of the word 'some' in front of 'responsibility'. The way it is mentioned now is like one can say 'somewhat dead' or 'a bit pregnant'. More or less undefined. And yes, this 'some' can be determined by reading the entire doc and depends on how DKIM is used, what fields are used for signing etc. But the words 'some responsibility' will not sound very exact nor very attractive to organizations who have to determine whether to invest in DKIM or not. So I suggest to either remove the word 'some' or describe in the same paragraph what this 'some responsibility' exactly means. /rolf Personally? I would go further to suggest to remove the usage of the term responsibility from the DKIM specification all together! Why? DKIM is no position today to provide any assurance to or for anyone to be indemnified from liabilities. With an unprotected raw Domain Signing protocol layer, all it does is give a potential plaintiff weight for a claim of willful Negligence when everything was done by the plaintiff to protect a domain (i.e. using ADSP) and a DKIM compliant receiver INTENTIONALLY ignored ADSP (on purpose) creating a situation where an end-user was HARM due to the receiver NEGLECT of a highly detectable malicious spoofed DKIM domain. I never like the usage of term responsibility, especially when there was a lack of a focus to protect exclusive domain signed messages from abuse. I highly recommend that the term is removed from the specification. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] running code, wildcard dep't
John R. Levine wrote: For a couple of days, I've been using a wildcard keys and putting a different selector on every message. It works great. Looking at the logs, I can see one key got looked up 32 times on my local server, so since I have three servers the total number was probably about 100. Now I just need better logs to figure out what message that was. What is your goal here? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
Douglas Otis wrote: I'm having trouble parsing that. Please propose alternate text, or show an example of what you're describing. I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Reputation can not fix this problem. Fobbing this onto the consumers of DKIM results goes against the goal of increasing trust in email, and against the spirit of doing our best at providing accurate results. Let's fix our mistake. The lack of focus for 1st party domain protection is what allowed this issue to fall through the crack. We tried our best to make DKIM a pure signing mechanism with an open ended implicit policy of unrestricted resigners, remolding the specs with out of scope wink wink design goals. MLM allowance or tolerance became a dominant goal over the principle benefit DKIM can provide - 1st party DOMAIN protection. The solution is an integrated solution. DKIM itself can not solve this. At this point, what's missing are HANDLING provisions for DKIM verifiers. A real POLICY protocol with 3rd party considerations is really the only thing that can help resolve this problem. Even Reputation Vendors can help here but they need to support POLICY too. Instead, the pressure has been to eliminate it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
these non-compliant RFC 5322 messages not be determined until it is known how messages are first passed or reach integrated DKIM processors. With an increase alertness of the possibility for these non-conforming RFC5322 yet DKIM compliant messages, receiver MTA may begin to perform this filtering at an increase level. This form of processing will minimize any implementation requirement for DKIM to perform this non-compliant mail check. In addition, enhanced MUA operations can address the situation as well with attentive awareness of non-compliant message displays. Senders concerned that their messages might be particularly vulnerable to this sort of attack and do not wish to rely on receiver filtering of invalid messages can ensure that adding additional header fields will break the DKIM signature by including two copies of the header fields about which they are concerned in the signature (e.g. h= ... from:from:to:to:subject:subject ...). See Sections 3.5 and 5.4 for further discussion of this mechanism. I would change this to: To address current or legacy email implementations that may not aware of these non-compliant RFC 5322 double header messages, DKIM Signers concerned their signed outbound messages might be particularly vulnerable to this form of attack can ensure that adding unexpected additional header fields will break the DKIM signature by including two copies of the header fields about which they are concerned in the signature h= tag e.g. h= ... from:from:to:to: subject:subject See Sections 3.5 and 5.4 for further discussion of this mechanism. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Take Three - Section 8.14
For readability, I will propose my 8.14 text change suggestions as a whole: 8.14 Non-Compliant RFC5322 Messages There are known conditions which can alter the originality of a DKIM signed message without breaking the existing signature validity. Since it is possible to maintain the integrity of the signature with known non-compliant RFC5322 message altered conditions, there is an increase possibility of abuse and exploitation of MUA displaying information which were not validated by the signature. Examples may be non-compliant RFC 5322 messages containing a 2nd 5322.From or 2nd Subject headers which were not hash bound to the DKIM signature, yet due to the nature of MUAs, the wrong header could be displayed to end-users. It is unknown how these non-compliant RFC5322 messages will be handled by backend MTA receivers and how MUAs will display them. It is conceivable, some MTAs will reject these messages while other MTAs may accept it but only after it has sanitize the message for user display. Yet other MTAs may be unaware of the multiple headers in these non-compliant RFC5322 messages. Under unchecked conditions, this can allow an attacker to replay a previously sent, signed message with a different Subject, From or To field. Despite the apparent scope of this requirement, there are implementation circumstances in which how DKIM processes these non-compliant RFC 5322 messages can not be determined until it is known how these messages are first passed or reach integrated DKIM processors. With an increase alertness of the possibility for these non-conforming RFC5322 yet DKIM compliant messages, receiver MTA may begin to perform this filtering at an increase level. This recommended form of processing will minimize any implementation requirement for DKIM to perform this non-compliant mail check. In addition, enhanced MUA operations can address the situation as well with attentive awareness of non-compliant message displays. To address current or legacy email implementations that may not aware of these non-compliant RFC 5322 double header messages, DKIM Signers concerned their signed outbound messages might be particularly vulnerable to this form of attack can ensure that adding unexpected additional header fields will break the DKIM signature by including two copies of the header fields about which they are concerned in the signature h= tag e.g. h= ... from:from:to:to: subject:subject See Sections 3.5 and 5.4 for further discussion of this mechanism. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
Alessandro Vesely wrote: On 26/Oct/10 06:58, Murray S. Kucherawy wrote: a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates. -1. How does might differ from MAY? I think it creates an IETF procedural bug and will promote another round of reviews or something like that. :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
Steve Atkins wrote: On Oct 26, 2010, at 1:49 AM, Hector Santos wrote: Murray S. Kucherawy wrote: 8.14 Malformed Inputs DKIM allows additional header fields to be added to a signed message without breaking the signature. This tolerance can be abused.. DKIM does not allow additional header fields. Yes, it does. Section 5.4 of 4871 goes into quite a lot of detail about that, and explains explicitly that you should list a header n+1 times if there are n copies of it already if you don't want to allow more headers to be added, or not if you do. I see the intent but it can reworded. I think my nit which I did not express, was how the immediate tolerance sentence that followed the opening text negatively alters its implied meaning. There is no tolerance. Its a DKIM feature and also a nature act of email operations for additional unsigned fields to exist, i.e. transport trace fields added to the already signed message. Maybe a better text might be: Per section 5.4, DKIM signed message allows the existence of unsigned header fields or additional unsigned headers added to the message during the transport process without breaking the original signature. This natural email functionality can be abused with the introduction of non-compliant RFC 5322 messages with two or more headers that can only exist once per RFC 5322. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] wildcards, was Focusing on 4871bis
John, The reported issue was about *mixed* TXT usage caused by wildcards. And it amounted to a large Domain Hosting vendor ONLY offering this for spf: *.example.com IN TXT v=spf1 .. And that created mixed query results after adding DKIM related TXT records. The proposed correction text is a) reminder to avoid using them and b) for verifiers to be ready to deal with it. i.e. be able to parse for the right DKIM related text string. -- HLS John R. Levine wrote: Forgive me if I repeat myself, but I still don't see anything wrong with this: *._domainkey.example.com IN TXT v=DKIM1; p=; n=revoked Do you have an actual use case for that sort of thing, or is it just an example to poke at the thou shalt not wildcard wording? That example above revokes all unknown keys. On this message, I've encoded a timestamp and the pid into the DKIM signature selector, so I can use my DNS query logs to get an idea of who's checking the signatures on what messages. These may not be fabulous uses of wildcards, but they are at worst harmless. There's a lot of places in the DKIM spec where we say if you do so-and-so, you'll be sorry. I'd like to avoid saying that unless we have a good reason to do so, and I only see problems with wildcards above the _domainkey label. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
then say that the From address in those messages is valid? I wouldn't. You might say, Well, they shouldn't oughta do that. Maybe wise people would advise them not to. But maybe they're not wise. DKIM doesn't weigh in on that. I will state that the DKIM process is making a series of statements of validity for all the parts (which includes the 5322.From) it hashes and binds to create and add a purportedly valid DKIM signature. When the DKIM verifier reproduces a valid signature from the bound parts, this is implicitly making a series of validity statements for these parts, including 5322.From. It is only a higher layer, i.e., POLICY and/or the out of scope reputation engines which take two different DKIM validated input feeds: POLICY_RESULT = POLICY(Author-Domain) REPUTATION_RESULT = REPUTATION(Signer-Domain) that can do any truth or DKIM validity confidence related concept. The fact is that probably 99% of their users just use the proper domain in their From fields, and it doesn't matter. The fact, for John Levine's domains, is that he knows and trusts his users, so he lets them do what he wants. Now, if his signing domain started developing a bad reputation because some of his users were sending mail as whitehouse.gov or whatever, he might change his policy. As might my service provider, if they started signing and saw their domain's reputation go south. I was not speaking of the invalid or unexpected or authorized usage. I am saying that what DKIM binds and signs are all parts of its validity claims. But that's all outside the scope of DKIM. DKIM only provides assurance of the *signing* domain, and that the message has arrived substantially unchanged from when it was signed (modulo h= and c=). And IMO, these are statements of validity, and it doesn't imply they are actually true. The point is that even if you wish to just use one side of the (market) coin where the signer is independent of the authors with a blind unrestricted signing practice, and your intent is to use the signing domain for some high layer evaluation, the validity of its bound parts MAY BE part or in whole of the total assurance the DKIM valid message wishes to provide, not just that of the signer information, but that of the authors as well. What is not being taking into account is that the author is still a fundamental essential part of the message and it is these DKIM adopters who will decide not only what fields are hashed and bound to the signature, but also what domain will be used for the signer (d=). My nit is one of a technical sales pov. One group is only focusing on a signer domain to satisfy some out of scope design goals and continues to water down the validity of the From that is required to be hashed bound to a VALID DKIM signature. Another group, and I believe one that most people will better understand is that DKIM will help protect the validity of the author address. To help increase DKIM adoption, IMO we should not water down the inherent DKIM statement of validity for the hash bound 5322.From which is another way of saying that there is a market of originating domains that decide what is signed and what signer domain will be used to represent them in some future out of scope reputation or currently possible VBR feeds. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
Dave CROCKER wrote: I have two submission domains that I use. One, gmail.com, which does DKIM signing, will only allow me to use a From address after it has sent a test message to that address and seen that I can access the test message. So it's made *some* level of confirmation that I owned the address at the time I set it up. Well, this is a reasonably common type of example. I think it confuses the difference between a signer's policies, versus DKIM semantics. It is certainly true that different signers have wildly different meanings behind their signing behavior. However there is nothing in DKIM that communicates a signer's policies. (Obviously, ADSP is an example of a value-added semantic, but as we all have been reminding ourselves, that's an additional function.) The critical point, here, is the question: What can the verifier know? They cannot know about differential policies and in particular the choice of what parts of the message are covered by the signature communicates no additional semantics. I think that is a different question but one that is based on a fundamental premise of having statements of validity for cryptographically protected parts of the message. Does all this suggest that one must begin with a presumption of false information? In other words before you can ask the question How/what can the verifier know? it has to begin with the validity claims made by the signature and its bound parts. So when you sign a message with signer-domain and it has a required bind for a author domain, these are two minimal statements of validity to be verified and perhaps confirmed by some higher power. Perhaps Policy with its author-domain feed, and/or perhaps out of scope reputation engines with its signer-domain feed. I think it is the latter that you are pushing for. I would like to keep DKIM pure and open to not just be about the signer domain. I believe that as long we continue to minimize the statement of validity a valid DKIM signature provides for 5322.From, the more these usual misunderstandings will persist. There is a reason why it doesn't go away and might we are trying to promote an obscure and abstract concept of an independent signer domain that today it is still very hard to grasp, especially with the lack of application demonstration. On the other hand, the majority of the industry can grasp and feel the issues regarding a 5322.From and can better understand the idea that DKIM might be a technology to help protect it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
Mark Delany wrote: The universe of email is replete with software that forgives messages which do not conform strictly to the grammar that defines what valid email looks like. This is a long-standing practice known informally as the robustness principle, originally coined by Jon Postel: Be conservative in what you do, be liberal in what you accept from others. Well, I'm clearly the outlier here, but I think be liberal is protocol nonsense that has been accepted as conventional wisdom for far too long now. Put another way, Accept crud and pass it on constitutes good protocol design? Gimme a break. More particularly, DKIM is a security protocol which means that being liberal is entirely antithetical and highly risky to boot. In short, I don't think any part of DKIM should be based on be liberal because it always trades off security. Really, its an inappropriate attempt in a history lesson and it actually doesn't apply here. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Focusing on 4871bis
Based on the discussions, and the recent entry to produce a counter proposal I would like to ask if we can trying to avoid putting this document through another cycle of review vs doing the job right with the correct technical information. For example, IDEALLY per your itemize list: 1) g= I owe you some data here. I don't know either way other than I have not seen (or focused on) any particular importance in the API we are using. 2) TXT Records This requires a code adjustment for DKIM DNS clients to parse for the v=DKIM1. This is required for SPF so any implementation that supports SPF and wishes to add DKIM will not be at a terrible lost with this adjustment. 3) Section 5.4 I think Jim's text makes the technical adjustments. But personally, I still believe there needs to be an 5322.From exception paragraph following the section 5.4 last header rule stipulated in the section. I think the choice has to been made on giving this to Team A to get the job done tomorrow, or giving this to Team B to get the job done right even though it may take longer. I personally do not see why the rush is trumping the need to do this right. All this began with a post I made providing Field Experience input regarding how a major MTA had already change how it implemented 4871 with an additional requirement for a single 5322.From and later finding out why they did this, leading to the security loophole discovery issue. This MTA's C/C++ open source API is not locked down to a particular vendor SMTP software and probably represents many other MTAs DKIM implementations, including ours. I just feel we are wasting time with semantics, as important as that may be IETF wise, but I'm afraid it seems to attempt to minimize the importance of having a straight forward technical correction description which may include code change requirements. Thanks for listening. -- Hector Santos, CTO http://www.santronics.com Barry Leiba wrote: We seem to be bush-whacking again, rather than staying on the trail. I don't mind (actually I like) some level of general discussion, but the chairs would like to focus on our immediate goal for now, so I'm asking folks to refrain, for the moment, from discussion that isn't directly addressing the text of 4871bis. That includes discussion of MUA issues. We can go back to talking about that later, but 4871bis is not the place for that, either from a protocol point of view or from a procedural one. We have reviews from Jim, SM, and John that the editors are working on responding to (John's is new enough that I haven't digested it all yet, and I'm sure the editors haven't either). We also have three significant issues that we need to make sure we have resolved satisfactorily: 1. How to handle a key record with empty g= and absent v= (section 6.1.2, list item 6). Proposed change: Remove g= altogether, along with all references to it. Surveys of what's out there show vanishingly few cases that use g= with any value other than * or empty, so this can be removed as an unused feature. 2. Advice about wildcards in TXT records. Proposed change: Add a note in section 6.1.2 warning about the effect of wildcard TXT records on finding DKIM key records. 3. The issue of multiple occurrences of header fields that may only occur once. Proposed change: Add text to section 5.3 recommending that verifiers check that the message complies with specs, and that they not validate a non-compliant message. Add a new section 8.14 to the Security Considerations, explaining the attacks that can be done using this exposure. We ask the editors to consider the latest batches of comments, respond to them as necessary, produce an -03 version, and post it when they have it ready. We ask all participants to speak up specifically about the three issues above, and let us know whether or not the proposed change is acceptable. The editors can post the specific text they're using, if we have anything to discuss about them. I believe we have agreement on the text for number 2, so we should be set on that one. I haven't seen a definitive poll about removing g= (number 1), but I *think* we have consensus on that. Text for number 3 is still being worked on. Please start new threads for these discussions, rather than responding directly to this one, and let's keep the threads for the three items above separate. And, again, we particularly ask all participants to refrain from other discussions that are not specifically about text for 4871bis, so we can get that document done. Thanks, everyone. Barry, as chair ___ 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] the usual misunderstanding about what DKIM promises
John Levine wrote: DKIM makes no statement about the validity of a sender address. d/ I guess I should have said Author address. DKIM makes no statement about the validity of an Author address. I keep reading this but there is no technical merit to show there is any truth to it, and in fact the only thing that is probably the strongest validity is the Author Address. No matter how many times it is stated and repeated, it will never be true. If one wants this to be true, then remove the required binding the Author Address, A.K.A 5322.From. I will go on to suggest that this ongoing design confusion of trying to water it down with unrestricted resigners is what got this WG all bogged down in trying to teach the world that the From really means nothing but only the signer does. It even reduces the incentive for adopters to invest in Domain DKIM Signing because they really have no power over controlling who can take control of their own messages or those that purports to be from them. They have really little payoff. My point is it really hasn't help DKIM to continue to water down the validity of the author address. If it wasn't a required binding, then there begins some truth to the statement. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] More on layer violations
-1. This is not a LAYER violation. DKIM is a protocol for RFC 822/2822/5322 data to: a) verify a message signature, and/or b) create a message signature. In order to do either requires INPUT that MUST be valid for the protocol to be fundamentally correct with its OUTPUT. Therefore it MUST make sure its input is 100% valid. This is not different than any function generator that checks its boundary conditions. A robust function generator MUST check its input otherwise you have faults, chaos, aborts, GIGO - Garbage In, Garbage Out. DKIM is fundamentally a security protocol and it will be insane to believe that it should allow GIGO to occur due to not checking it input validity. A Layer Violation is when you are asking for data bits that in 821/2821/5321 (or another our feed) and/or also producing BITS that other layers like a MUA might use. We are not doing the former but would be if we bind bits like a Return-Path. We are differently doing the latter with the creating of more bits for other LAYERS to use. DKIM validating its INPUT is not a layer violation and in practice, it will be extremely bad product engineering. In fact, I would go as far to make it an ethical engineering responsibility for ALL DKIM components to make sure its not a GIGO engine. Now, if that doesn't jive with the IETF DOCS well, thats an entirely different issue. Most implementators are not going to GAS (Give a S$$$) what that docs says or doesn't say if it not providing what is fundamentally necessary. The DKIM component MUST check its input and at least one independent API has done so (on the verify side for 5322.From only). It could not pass the buck to 822/2822/5322 message generators or verifiers. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: You can add OpenDKIM to that list. Like I said, it already does do the validation, but that's because RFC5322 says so, not because RFC4871 says so. And I think that's the way it should stay. Take a tour through the eleven parts of Section 7 of RFC5451, and then Appendices A and C. They provide all kinds of warnings about misinterpreting the data provided, which amounts to pretty firm implementation advice, and identifies ways you can shoot yourself in the foot. But none of those sections are normative. (Actually there are two SHOULDs in 7.4, but in retrospect they shouldn't really be there.) That's what I'm advocating here: The normative stuff defines the core mechanics of the protocol itself, and the informative stuff explains why it's done that way, detailed implementation advice including stuff about other layers, and how one should (and shouldn't) interpret the output. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] FIX THE (DOC) PROBLEM!
That is a different issue all together. We are talking about a security threat that fell through the cracks during the RFC 5016 production in this group. It MUST be corrected - pronto, not later, not in another I-D, not in another WG. No - in 4871bis. It is rather tiring to seeing the rationalization on how to try to avoid not directly talking about the security loophole and resolution. Whether its MUST, SHOULD or it should not do anything and pass the buck to a lower layer. That is all nonsense. While in an integrated environment, you have all sorts of ways to resolve this, a DKIM is an independent RFC 5322 Protocol Technology - therefore it inherent all the design requirements to make sure that GIGO (Garbage In, Garbage Out) does not occur. Lets fix the DOC BUG and be done with it - thats forward progress. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com J.D. Falk wrote: On Oct 21, 2010, at 11:13 AM, John R. Levine wrote: The verifier MAY treat unsigned header fields with extreme skepticism, including marking them as untrusted or even deleting them before display to the end user. That's an example of the bad advice that I think we should drop from 4871bis. It does nothing to improve robustness or interoperability, just offers unsolicited advice to MUA developers. As this conversation has continued, I'm increasingly convinced that the only sane path forwards is to have a separate Informational or BCP document containing MUA considerations. The only question is whether that'd be restricted to considerations we've discovered while discussing DKIM (in which case it might fit in this WG), or open to all the stupid MUA tricks this community has seen since rfc733 (which should probably be a new WG.) Either way, I'd be interested in participating in the effort. ___ 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] double header reality check
MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, October 20, 2010 1:55 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] double header reality check SNIP There has been talk of applying DKIM to technologies like Usenet and HTTP output. Packing DKIM with mail-specific verification requirements could prevent such things from happening. Shall we also add a but only when used in the email context clause? Seeing as the M in DKIM stands for Mail, we don't have to put a but only when used in the email context clause. If a DKIM like approach is used for other protocols then we might reasonably text specific to those protocols - DKIH (Domain Keys Identified HTML as an example). I guess because we are already integrated with different mail formats, I don't see the difference other than having implementation specific setup features. For example a signing setup with a target rule Signer Domain::Target Domain where the association will enforce certain headers to be signed. In the case of usenet (or nntp specifically), the considerations might be: - enforce Path: header - enforce (maybe) Newsgroups: header - relaxed signing To: header (since its To: ALL for news) But if you want to see how email is gated into public newsgroup areas, check out news://news.winserver.com (use an anonymous account to login). You will see how newsgroups are used for various list. One for the IETF-DRAFT submissions and other list areas shown as local public newsgroups. One of interest where DKIM is used is the SPF-DISCUSS list/newsgroup where you can see the 10/17/2010 article titled: [spf-discuss] SPF Mail Summary Report and if you view the message source and headers, you will see the Authorization-Results: header: Authentication-Results: dkim.winserver.com; dkim=pass header.i=listbox.com header.d=listbox.com header.s=launch; adsp=fail policy=all author.d=winserver.com asl.d=listbox.com (unauthorized signer); dkim=fail (DKIM_BODY_HASH_MISMATCH) header.i=winserver.com header.d=winserver.com header.s=tms1; adsp=pass policy=all author.d=winserver.com signer.d=winserver.com (originating signer); When our system generated the weekly Summary Report, it was DKIM signed and exported to the spf-discuss mailing list. The list server than broke and resigned it and when the copy came back to us, it will DKIM verified and put into the newsgroup area. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] What shows up with duplicated headers?
John R. Levine wrote: Here's another batch of spam with extra From or Subject lines. I see the same thing as last time, the extra subjects are all the same, and the extra From lines look like bugs, not attempts to evade filters. The spam with 6,981 From lines is impressive in a wacky way. R's, John SNIP wow! I definitely have to pencil in time this weekend to scan the archives (I think I have some as far as 1998) to see how pervasive was this issue. Good show john. --- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John Levine wrote: OTOH, we already have a SHOULD that tells MUA writers to splatter the d= field somewhere in the GUI where the user can't ignore it Ugh, you're right. Now that I look at it, I'd like to completely delete Appendix D, since it says some things that are just wrong, i.e. language that implies that the signature contains someone's email address, and some stuff that hasn't been implemented and quite possibly never will be, e.g., highlighting the signed parts of the message. Personally, I have no idea which signing domains are credible and which aren't, and I have no interest in my MUA showing them to me so I can try and guess. That's much better handled in the MTA or MDA, using something like VBR to check the signer's credibility. John, Please take a step back (into the balcony) to reflect on what you are saying here. I personally appreciated your recent input in the threads hitting the right notes. I think Appendix D touches base with some impractical MUA considerations regarding different bits - its either good or bad. I've written several (long) drafts of a response and concluded with something I believe we already discussed in years past: MUA trust of the Backend Information provided. Its a simplistic statement but hopefully one can see based on the realistic backend/MUA operations. Overall, we have two types of MUAs: - Online MUA with complete backend control of what is rendered based on a suite of backend available information. - Offline MUA where the backend has to pass information to the MUA in a common standard data format we call RFC 5322. Lets use gmail or yahoo as an example as you once reference these as quick ways to test verify signature generations. These were online MUA methods and both systems had control on how to convey valid DKIM signatures with their online GUI display. But as you are aware, the user can also setup his account to pick yup mail via POP3 (or IMAP) for users who wish to use an RFC-based offline mail reader (like Outlook, Thunderbird, etc). In this case, we have yet to developed a way to convey the same online experience in a time-shifted offline manner. Gmail can only pass the A-R (Authentication-Results) header. But I believe we concluded long ago the general MUA can not trust headers like A-R. The offline MUA developer is not going adding support for A-R unless he is 100% sure it is a trusted header generated by the back end host. ISP, ESP, etc. If the offline MUA does not get what is needed from an authenticated mail pickup, then it may redundantly repeat the DKIM verification. It might do this anyway to cover the market of non-DKIM supportive mail pickup host. Overall, the point is the backend has complete control of what to display for its online access user interfaces. But for the offline MUA, there wasn't muuc we done to give them trust and avoid repeating the DKIM verification. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
These are not MSA or MDAs so its a different set of assumed preconditions. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine Sent: Tuesday, October 19, 2010 2:47 PM To: DKIM List Subject: [ietf-dkim] double header reality check So it establishes a false sense of resolving a security issue. Hmmn. I could reiterate for a fourth time why the double header thing is only a security issue in the context of DKIM, but there's clearly something else going on that prevents people from getting it. Obviously you believe your view is unassailable, but please stop asserting that people who don't see it your way are automatically thick. Here's a question: in the absence of DKIM, does anyone think that doubled headers present a security problem? I have also repeatedly said yes to this question. If so, what is the problem, and how has it been addressed in the past? Any filter or agent that makes any kind of filtering, routing or sorting decision based on any header field which in turn presumes there's only one such field without actually checking is a potential security concern. That extends not only to routing and filtering of messages, but also to their rendering. Examples: - procmail, which by default acts on the first match it finds without first confirming RFC5322 validity, so if I know or can figure out your rule sets I can do something that will get bad mail into a good folder or other internal mail stream, and then an MUA could render the From: or whatever field that wasn't the one subjected to filtering (as your own experiment showed) - SpamAssassin, which can reformat possible spam by wrapping it in MIME content using new header fields extracted from the original message, but only takes one (the last) of each of the ones listed in its man page when doing so, meaning a filtering action can be taken that results in false data being rendered in the report; then the user sees that something he/she wanted was tagged as spam and complains (there may be worse exploits, that's just the most obvious one after my code review) - Mailman authenticates postings and subscription requests based on the first instance of From or Sender it finds, but relays both so a downstream filter or MUA would see both and thus potentially make a wrong handling (rendering/filtering/routing) decision - majordomo, same as Mailman There were several instances I found as well in other lesser-known filtering tools, but these ones will hopefully provide some context. And since those problems are there in the code for each I just downloaded and reviewed, I would say they have not yet been addressed. Since the issue is an attempt to fool users, those seem to me to be in the same family as the other thing we're talking about. And none of them have anything at all to do with DKIM. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] double header reality check
Mark Delany wrote: Only once tools and UAs take advantage of DKIM, do these attacks become relevant. That's why I think this is a DKIM problem. We are wanting tools and UAs to take advantage of DKIM but by doing so they are possibly making themselves more vulnerable to attackers. +1 And this is why 1) we MUST establish the DKIM boundary conditions for 100% success and 100% failure. You have to move all parties into the same playing field and those that are not compliant are pushed out. 2) the conflict in the deployment to allow for unrestrictive resigners with no willingness to establish 3rd party policies simply makes everything even more indeterminate. How can we tell when the valuable signer identity is good, bad and/or exploiting the originating domain? Unless we get an solid anchor for 100% Zero False Positive boundary conditions, it makes all this very hard in what is already very complex. DKIM has the high potential to become the next relaxed Return Path dilemma the industry knew since the 80s was insecure, but not yet highly exploited where we didn't do much about it. Every good idea has a solid well defined problem it solves. DKIM was one suppose to be the alternative to SPF because it has the PATH problem. By deemphasizing policy and opening the door for unrestricted resigners, its now become a last signer authentication protocol. Anyway, to get back to the problem, we need to do less subjective analysis and just try to get the deterministic bits of DKIM well defined - valid input and it needs to check it probably is only thing left. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] What shows up with duplicated headers?
John R. Levine wrote: I dunno what that tells us, other than that whatever attack is enabled by duplicated headers, it doesn't appear to have happened yet. Maybe it has and it is the best kept secret loophole by spammers and spoofers. Maybe there should be more research into the site mail archives to see how much of this was among us fooling users for a long time. Maybe it slowed down as the larger ISPs or ESPs began to filter invalid RFC 822, 2822/5322 messages like gmail.com does now. But then again, gmail.com is relatively new entry. I can tell you that in our 25+ year old mail package which was the top 5 BBS mail packages in the 80s and early 90s never looked for this as far as I recall and only recently I added a server script to check for it after discovering why Alt-N modified their API to check for the multiple non-hashed From: headers. Alt-N input on this was they did not see any evidence of wide usage other than the fact it was a customer report and they updated their DKIM API to add a new requirement for verification - all 5322.From must be hashed. That is why the President Obama message got into here. It had two 5322.From headers which was signed by my system when it sent the message to Dave's system. Dave's system validated the double from and resigned without hesitation. However when I sent the double from without a valid signature, it barfed the message. What your research shows the problem is REAL. What we don't know is how much it has effected the end-users as part the phishing and spoofing schemes because I will venture that most systems do not check for this. Thanks to DKIM - now they will and for the legacy systems adding a DKIM standalone component, the DKIM component MUST also check for this loophole. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: 4871bis - section 5.4/5.5 clarify 5322.From requirement
Charles, I was showing what already is written and suggesting that it might need clarification. Charles Lindsey wrote: On Sat, 16 Oct 2010 05:09:53 +0100, Hector Santos hsan...@isdg.net wrote: This probably means that it should clarified what that 5.4 sentence means and also the next section 5.5 5.5. Recommended Signature Content .. The following header fields SHOULD be included in the signature, if they are present in the message being signed: o From (REQUIRED in all signatures) But that is weaker what what it already says, which implies saying h=from even if NO from is (contrary t0 5322) present. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
SM wrote: Hi Hector, At 09:28 16-10-10, Hector Santos wrote: From an IETF procedural angle. :) I'll comment on how I read what the WG Chairs said in general terms. If you believe that the process followed is not fair, you could discuss the matter with the WG Chairs. I'll quote a message from a WG Chair [1]: SM, I think you made a correlation I did not expect. But my question was: If 4871 does not speak of requiring the DKIM client of parsing merged TXT records to look for its specific inputs, then section 3.6.2.1 needs to make up for this dearth of verifier design information. I ask because in Murray's suggested text: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. I like it, but from an IETF standpoint, doesn't the last sentence imply a 'change of code' thing that we try to avoid here? There is, for example, a should in the text you quoted and some people may nit about it. Would the above text force a change of code in your implementation of DKIM? I think the way it is stated was design to avoid this. Right? Yes, it could be so. That is all I wanted to point out or ask about. My original text did not try to make any additional Verifier requirement even though I knew that that is what is required because DKIM failed or at least inadequately envision the mixed TXT issues. I'm not saying the text below should be used, but to point out it was addressed as a DNS management guideline. The DKIM public key TXT record MUST not be mixed or merged with other TXT records, i.e. SPF. In addition, make sure other TXT records with Wildcards do not conflict with DKIM public key lookups. I was trying to appease the IETF procedure here but not saying anything more about a verifier needs to do. But technically I do agree that we should be more specific and as Murray wrote Verifiers should expect this to occur and plan accordingly. I was just wondering is this was going to be a contentious point. Again, the posted issue was about the mixed TXT issue. I understood that DKIM was not specific regarding dealing with mixed TXT. What I don't know if that was on purpose, a presumption that was well understood a verifier will look for v=DKIM1 or just fell through the crack. In any case, I didn't want to post an issue that would add more requirements, but simply highlight for DNS management people to not make it difficult for DKIM adopters. But I think that might not be good enough and we might need to go ahead and add text about a verifier looking for the right string in a merged TXT response, just like SPF specification provides for its implementators. I am just wondering if you guys (the editors) recognize what appears to be a technical need conflicted with IETF procedure time lines to get this doc out the door. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] How MUAs render mail
Wietse Venema wrote: Mark Delany: My problem is that if some valuable domain like paypal sends me a bunch of bits that I or my MUA or my MTA ties to paypal.com then the end goal of DKIM is, IMO, that those bunch of bits I see are the ones that paypal sent. No more, no less. But the user does not see a bunch of bits. The user sees the combined result of software layers that render those bits. DKIM has no control over that rendering process. Well, not widely yet, but you do have Gmail and Yahoo Online MUA show info regarding valid signatures. That is a DKIM controlled input bit. We are almost ready to begin similar MUA changes as well starting with our Online MUA. But before we do that, we need to get a 100% clear indication of the expectations. Right now, it seems to be a low key item. DKIM can only guarantee that what you RECEIVED is what I signed. To get what you SEE is what I signed semantics, one could do the following: [SNIP] [SNIP] I see you have a funny bone in you. :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
MH Michael Hammer (5304) wrote: This is no more presumptuous than expecting that MUAs will adapt to consume the output of DKIM as it stands now. The question is the value equation. I'm not in a position to answer that question. Perhaps we should try to get some of the MUA folks to join the conversation. It may be that some of the well known ones go... hey, never thought about this issue and yeah, we will look into fixing it based on the wider scope. On the other hand they might inquire if we are smoking crack (Just trying to give the two extremes of responses). I'm a MUA author of BOTH types and people forget that there are TWO kinds here. We have: Console based Mail Reader/Writers Online Interface (Dialup/Telnet) telnet bbs.wisnerver.com or 305-248-7815 A Frontend Native GUI ONLINE Interface http://www.winserver.com/public/wcnavigator.wct A Frontend Web-based ONLINE Interface http://www.winserver.com (you have to log in) Two QWK, RFC 822/2822/5322 Offline Mail Reader/Writers: http://www.santronics.com/products/olx/index.php http://www.santronics.com/products/sxpress/index.php Two Administrator Report Reader/Writer Online Interfaces http://www.santronics.com/products/pxpress/index.php A Outlook Exchange Component http://www.santronics.com/products/winserver/Exchange.php And very important NNTP (News) and POP3 (Email) Mail Servers to support ALL RFC based Store and forward offline mail reader/writers. All MUAs, including are feed by the backend. It is the BACKEND that feeds the children what it will eat (see). We can ALTER and DO whatever we please to give whatever the ILLUSION we want the MUA to see. This issue is a BACKEND issue whether we want to deal with it at a: MSAAuthenticated Submission (For Local or Remote User/Relay) MDANon-Authenticated Submission to LOCAL USER ONLY or at some DKIM integrated component. To assume that this is should be PUSHED first to MUAs is BAD engineering and NAIVE. But that doesn't mean they don't have to look for it just in case an 3rd party interface software (like an RFC-based mail/writer) whats to make sure that all backends are correct. So as I said in an earlier post, technically, all parts need to deal with this but more so the DKIM API because this is part of their Reason For Living in the first place - mail integrity. Its like a Neighborhood Watch Program vs Real Cops. Everyone will need to deal with it. But the BACKEND is the #1 place to deal with this especially for systems that only have Online Interface devices and/or Legacy Online or Offline mail readers who require (and don't even think about it) that the backend mommy give them clean food to eat - not poison, dirty food. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM Component Responsibility
Murray S. Kucherawy wrote: Current implementations, especially the two library ones that are referenced most often in here, haven't the functionality to cause header fields to be removed, prefixed, reordered, modified, etc. This change would require them to be overhauled to extend their reach into what the MTA can do. That expansion of scope of DKIM process to me requires a recycle at Proposed Standard. What started all this is one of these API dealing with it with the verification and I pointing this out. However, we did not know why it did this and we later found out. Their solution was only on the verification side with an added requirement that all 5322.From be signed - the default behavior. So any belated injection of a 5322.From header would invalidate the signature which I believe will cover the majority of the loophole. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
FWIW, the telnet mail interface typo fix should be: telnet bbs.winserver.com -- HLS Hector Santos wrote: I'm a MUA author of BOTH types and people forget that there are TWO kinds here. We have: Console based Mail Reader/Writers Online Interface (Dialup/Telnet) telnet bbs.wisnerver.com or 305-248-7815 A Frontend Native GUI ONLINE Interface http://www.winserver.com/public/wcnavigator.wct A Frontend Web-based ONLINE Interface http://www.winserver.com (you have to log in) Two QWK, RFC 822/2822/5322 Offline Mail Reader/Writers: http://www.santronics.com/products/olx/index.php http://www.santronics.com/products/sxpress/index.php Two Administrator Report Reader/Writer Online Interfaces http://www.santronics.com/products/pxpress/index.php A Outlook Exchange Component http://www.santronics.com/products/winserver/Exchange.php And very important NNTP (News) and POP3 (Email) Mail Servers to support ALL RFC based Store and forward offline mail reader/writers. All MUAs, including are feed by the backend. It is the BACKEND that feeds the children what it will eat (see). We can ALTER and DO whatever we please to give whatever the ILLUSION we want the MUA to see. This issue is a BACKEND issue whether we want to deal with it at a: MSAAuthenticated Submission (For Local or Remote User/Relay) MDANon-Authenticated Submission to LOCAL USER ONLY or at some DKIM integrated component. To assume that this is should be PUSHED first to MUAs is BAD engineering and NAIVE. But that doesn't mean they don't have to look for it just in case an 3rd party interface software (like an RFC-based mail/writer) whats to make sure that all backends are correct. So as I said in an earlier post, technically, all parts need to deal with this but more so the DKIM API because this is part of their Reason For Living in the first place - mail integrity. Its like a Neighborhood Watch Program vs Real Cops. Everyone will need to deal with it. But the BACKEND is the #1 place to deal with this especially for systems that only have Online Interface devices and/or Legacy Online or Offline mail readers who require (and don't even think about it) that the backend mommy give them clean food to eat - not poison, dirty food. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Monday, October 18, 2010 4:24 AM To: DKIM Subject: Re: [ietf-dkim] layer violations, was detecting header mutations after signing Irrelevant for the current discussion. On the contrary, that is precisely the attack of interest, so it is supremely relevant. You claim it can be thwarted by other means, but have failed to explain exactly how those other means would work. On the contrary, none of this is within the prescribed scope of DKIM. ADSP and reputation (the latter of which is explicitly out of scope) are predicated on DKIM's output, not part of its input or its mechanics. From an IETF standpoint it might not be, but from an engineering standpoint, I beg to differ. These topics are distractions from the effort of solidifying the DKIM specification for advancement along the standards track. That's what I believe he means by irrelevant for the current discussion. We need to stop blaming others. Borrowing an old QA engineering motto: Getting it Right. The First Time! Otherwise, you get what you have today. Note, that is not about perfection, but rather proper engineering to minimize customer issues even it if means a little more upfront cost. In my view, a good bit of the issue was manifested by the on-going out of scope design considerations with a) defocusing of Policy and b) greater allowance for unrestricted resigners and participants were providing input that there was an engineering problem with this. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Invalid RFC5322 related DKIM Implementation requirements
I think most people understand this: - DKIM SHOULD be checking its input, - With increase awareness, the backend MTA receivers SHOULD checking for these Special RFC5322 multiple header issues. Whether SHOULD should be changed to MUST is not a concern to me, either way, there is guidelines the DKIM component and the system it is integrated into needs to address as a new consideration to lock down related implementation requirements. How this is done (written) in 4871bis, I leave the RFC doc experts to do this and if they need to write it in a way that will not slow down DKIM to draft standard, as long as the above semantics are provided, I think the job is done. The h=from:from kludge I see as a temporary solution for engines that are able to work with that preparation and I am on the fence if this should be added to the 4871bis. I see it as a short term note because ultimately, even will be on the same plane to understand the RFC 5322 mail bots need to do this, especially on the receiver side. But more important, I think it does require code change and its not just an Operator DKIM options. SSI and ALT-N has agreed that SSI can enhance the library for general purpose usage with the updated DKIM flexibility needs, especially on the ADSP extension side as it was hard coded for ADSP as it is written today with a subjective but hard coded rule on how DKIM=ALL is interpreted. The changes have not be submitted to the version control system yet and won't be until Alt-N final approval. I changed ALT-N DKIM API (LIBDKIM) and it would able to now offer the h=from:from kludge but this was not the reason for the change. I can't say how OpenDKIM does it, but the LIBDKIM default minimum API usage behavior is to sign all the headers and it is hard coded to skip these headers only: X-* Authentication-Result Return-Path Howwer, the LIBDKIM API provides two application level methods on what headers to sign or skip: 1) Call Back per Header with a boolean result. return true - sign it return false - skip it (don't sign it) 2) optional string szRequiredHeaders For general purpose usage of the API, the callback method will not be possible for embedded p-code server side languages, so the only other way is to pass the optional szRequiredHeaders string. However, szRequiredHeaders only allows you to set the headers to include it might have skipped. It is not a way to define the exclusive specific headers to sign only. So I added a logical flag option: int nUseRequiredHeadersOnly; // 1 - used szRequireHeaders and // exclude the rest. 0 - fallback // to default sign all headers // behavior that allows you use szRequiredHeader as the only headers to sign. I did this because it was signing headers I didn't think it sign including Received: which 4871 recommends as a SHOULD NOT. I wanted operator defined local policy options to specified headers it wanted to sign on a per DKIM author/signer domain setup basis. From an product engineering standpoint, it needs this flexibility. But the current open source version is not capable of using this h=from:from kludge and that probably means any implementation of this API can't do it as well unless it has altered it to do something like we did. Anyway, my main point is that I don't think we will cover all possible methods to resolves without deeper working group analysis and hence delays. But we can say the basic ideas as above: - DKIM SHOULD|MUST checks it main inputs - Receiver MTA SHOULD|MUST check RFC5322 more strongly with a specific guidance on what it should focus on in order for DKIM to be protected. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis Sent: Monday, October 18, 2010 3:33 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Data integrity claims Should the charter of a security related protocol need to anticipate minor modifications to a verification process, that appears essential for ensuring a DKIM signature is not inappropriately associated with an incorrect From header field? Any effort, security or otherwise, needs to scope itself correctly. We, for very good reasons, chartered ourselves originally to come up with a system that requires minimal infrastructure changes. I claim that inserting an Authentication-Results field is minimal, as it is incremental. But if we also claim MUAs and users pretty much ignore that, which is the case today, then it (or any solution that is strictly an annotation of some kind) fails to have the protective impact you're seeking. The only option then is to obstruct delivery in some
Re: [ietf-dkim] Protecting messages, not MUAs, MTAs, or anything else
John R. Levine wrote: So, uh, can we agree that Jim's SHOULD language to tell people to do this is a good idea? Yes. +1. I think I was the first to agree with Jim's input and didn't see much follow up except you and maybe another person. Maybe Barry can provide a repeat of the exact change proposal and get a preliminary show of hands. Personally? I think from a reader standpoint: Additional 5322.From Exception Paragraph in Section 5.4 after the paragraph about use the last field found That is where a reader/developer will begin to scratch his header on what headers to sign and verify. So it needs a quick by the way paragraph regarding a special exception for 5322.From against the use the last field rule in the previous paragraph. But in the name of moving forward, Jim's text does the job. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] FYI: TXT Record setup resolved by Domain Hosting Provider
FYI: Maybe there are lurkers here from Network Solutions reading my recent posts, but the issue with their web-based DNS Records Manager inability to allow domain customer to make TXT records without a sub-domain has been resolved. It was done by allowing a special sub-domain input: @ (none) This allowed the removal of wildcard results and the separation of SPF records from DKIM TXT sub-domain records! Our customer using our new DKIM system is happy (the bottom line) and I'm happy because we were ready to take over their domain name server hosting. I think this shows whether or not there were vendor engineers lurking the DKIM WG and read the post I made, having some insight in the DKIM 4871bis regarding mixed or wildcard TXT responses will preempt issues for future DNS management developers and help increase DKIM adoption by small to mid size domains with less pain. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
SM wrote: You can tell me if I am wrong here cause I am trying to make sure I It is not up to me to determine whether you are wrong. :-) From an IETF procedural angle. :) 1) Verifier TXT record parsing I checked for this, but did not find it, but was a quick scan. If the DKIM specs says that verifiers MUST be ready for different TXT records merged in the DNS Query response, it MUST parse for the string v=DKIM1 If this is the case, then I don't think we need to add anything. Its all good. That tag isn't always included in the DNS record for backward compatibility with DomainKeys. And it is optional. As you are doing a query for a TXT RR, expect garbage. However, in my personal engineering opinion, it probably should add a note for verifiers to be ready for multiple string responses. From RFC 3833: Much discussion has taken place over whether and how to provide data integrity and data origin authentication for wildcard DNS names. Conceptually, RRs with wildcard names are patterns for synthesizing RRs on the fly according to the matching rules described in section 4.3.2 of RFC 1034. While the rules that control the behavior of wildcard names have a few quirks that can make them a trap for the unwary zone administrator, it's clear that a number of sites make heavy use of wildcard RRs, particularly wildcard MX RRs. Regards, -sm The difference is that MX records are well structured fixed RR records, where merged TXT records have a multi-technology mix with multiple non-fixed structured definitions. So the client has to be aware of all of them or be savy enough to look for what for what it wants. But my question was: If 4871 does not speak of requiring the DKIM client of parsing merged TXT records to look for its specific inputs, then section 3.6.2.1 needs to make up for this dearth of verifier design information. I ask because in Murray's suggested text: The use of wildcard TXT records in the DNS often result in something coming back from a query that isn't a valid DKIM key record (and ADSP will encounter the same thing). Verifiers should expect this to occur and plan accordingly. I like it, but from an IETF standpoint, doesn't the last sentence imply a 'change of code' thing that we try to avoid here? I think the way it is stated was design to avoid this. Right? -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
Ian Eiloart wrote: I think the emphasis in John's email was on expect reasonable results with existing MUAs If DKIM is any part of the evaluation process, then that's all thrown away if MUAs are showing the wrong email address as authenticated. MUAs are like children. They eat what we feed them and they can't exist without a backend. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
Murray S. Kucherawy wrote: Levine wrote: Aw, come on. How many millions of people still use Outlook Express on Windows XP? Switching MUAs is painful, people rarely do it. ...meaning MUA developers won't bother to do something about it once the attack is plainly visible and they're used as examples, because since users won't switch anyway, there's no motivation? The backend will address it first before the MUA needs too. Murray, most people are not haters and don't draw a line between good and bad because one isn't perfect and therefore begin to switch software like cheap wine. Since DKIM is betting its future on increase mail integrity and verified identities, it is a fundamental requirement that it checks key parts to make sure the integrity stays in tack. Passing the buck (or assuming others are better suited to deal with it) is not practical and bad PR for DKIM. In reality, all parts need to check for this, the MUAs, the backends and above all because of the extra special needs for trust - DKIM. The backends can't presume all the different MUAs used will address this, so it needs to address it. The DKIM components can't assume the backend or MUAs will address it, so it needs to address it itself. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with SPF TXT records
Folks, I really think we should use the opportunity to add a note about DKIM adopters having potential DNS setup issues due to wildcard SPF records. When section 3.6.2.1, SPF was probably still growing and not wide spread with Web-Based DNS managements from ISPs. Today, a special Add SPF record option is available. At least at one ISP/Domain Registrar (one of the original biggest), it only allows a wildcard TXT record to cover the non-prefix SPF query. This conflicts with added DKIM and ADSP dns records. The section already has an INFORMATIVE OPERATIONAL NOTE advising not to use wildcards for DKIM public keys records. What I am suggesting is another short INFORMATIVE OPERATIONAL NOTE, not about a tutorial on DNS management, but maybe just saying: INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records for SPF records may conflict with DKIM TXT sub-domain TXT records. DNS management software should not require only Wildcard SPF entries and should allow for non-prefix SPF TXT enries. The readers of this document will include web developers for DNS zone file management when considering DKIM record support and having this new informative note will guide them in not being conflictive with DKIM TXT record lookups. The only reason I like for people to consider this is because I got an email today that Network Solutions isn't going to address this issue for the customer. So like Murray likes to admonish those for lack of compliancy and to encourage to fix problems, having the helpful information operational node will help admonish DNS management software developers to maybe correct their current implementations. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Steve, I believe its about protocol consistency. While the main focus is DKIM progress, its issues and resolutions are related to ADSP as well as its a WG product as well. For example, ADSP implementations now know that they need to make there is only one 5322.From as well. Like most software, when it has a header = GetMailHeader(From:) it is not expected to return a list of headers, but a single entry and that generally done by finding the first one. In short, we have marked this on the WG to-do list for ADSP updates if any, and implementations now know what they need to add to their ADSP support. Its all about synergism. We can't just completely ignore it and then miss something that needs to be done later. -- HLS Steve Atkins wrote: On Oct 15, 2010, at 9:50 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Charles Lindsey Sent: Friday, October 15, 2010 7:30 AM To: DKIM Subject: Re: [ietf-dkim] detecting header mutations after signing And if we are not going to fix ADSP (yet), then the only way we can stop that particular exploit is to fix DKIM. Arguing that ADSP is a completely separate discussion will achieve nothing. If that's consensus, then we're on the slippery slope of fixing DKIM to deal with flaws at all layers above it. And we'll never be done. +1. Any bug fixes for ADSP need to be done at the ADSP level. If there's a bug that needs fixing at the DKIM level then if should be something that clearly needs fixing based on DKIM usage. (And I think that the very narrow case of messages that violate 5322 through multiple headers *may* be such, but any justification of that relying on ADSP isn't helpful). Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
For the record, what you were told was that if your childish action of filtering me extended to telling others to filter me, that would be grounds for tort. Apparently, I am not the only one who feels the consensus process is being skewed by key editors filtering of WG Participants that don't always agree with with the direction or changes to the WG documents. While you have all the right to filter your WG mail, that doesn't sound like good IETF engineering with the requirement of being open minded. You being a key editor of the nearly all the documents know requires you to BACK OFF and take in all the input and try to block them in their inputs. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Friday, October 15, 2010 10:17 AM To: IETF DKIM WG Cc: Barry Leiba Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition So I strongly object on procedural grounds for authors who kill file people in general, and for those asking for consensus in particular. In fact, I have been looking at RFC 2026 Section 6.5.1 (a) as an reason to appeal based on the principal key editors are knowingly filtering input from WG participants. I know both Dave and Murray are doing this and both are key editors of this document. This creates problems and also unnecessarily increasing the volume of input from people who don't believe they are being heard. I was threatened with legal action on the basis of tortious interference if I continued to disagree with one participant's technical arguments or professional conduct on this list. I have thus elected not to engage that person any further in any discourse whatsoever on the list absent a withdrawal of that threat and some kind of guarantee of future civility. I have serious doubts the IESG would find fault in that choice on appeal. The IETF has dealt severely with other participants that have taken that attitude in the past. ___ 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] 2 Day Collection Stats
Murray S. Kucherawy wrote: And, anticipating the next question(s): Signatures with other l= values that were in turn larger than the message received: 10389 Subset of those that still passed: 9870 (95%) Subset of those that still passed and looked like list traffic: 5504 (53%) Based on that it looks like l= is pretty effective, but not very widely used. I did a short testing on this (but turned if off for now) where for one domain, I prepared the signing to: - use l= - excluded Subject in h= and the list mail survived with the original signature and the new resign signature. What it basically told me that we (my implementation) might have to add feature for a Target signing rule: if target is for a list then use - use l= - excluded Subject in h= otherwise - don't use l= - subject is in the h= But right now, list mail resigning strips the original. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
SM wrote: This is just to jump start suggested text. Others can add/change whether they think helps: The DKIM public key TXT record MUST not be mixed or merged with other TXT records, i.e. SPF. In addition, make sure other TXT records with Wildcards do not conflict with DKIM public key lookups. That text adds a requirement in an informative note. SM, You can tell me if I am wrong here cause I am trying to make sure I understand the IETF angle to this but I also a product developer and have to look at the customer support angles as well. 1) Verifier TXT record parsing I checked for this, but did not find it, but was a quick scan. If the DKIM specs says that verifiers MUST be ready for different TXT records merged in the DNS Query response, it MUST parse for the string v=DKIM1 If this is the case, then I don't think we need to add anything. Its all good. This would be an implementation bug in our software if indeed that is what happening with invalid selector DKIM fails. 2) If #1 isn't part of the specs.. then I think there should be some note regarding working with other TXT records and to provide guidelines to DNS management software people to not enforce a wildcat only TXT record management solution for their customers. The note should not add a requirement for verifiers though (if this is going to an IETF RFC issue). However, in my personal engineering opinion, it probably should add a note for verifiers to be ready for multiple string responses. Note: For SPF, verifiers are already expecting and looking for the v=spfxxx strings in merged TXT records responses. This is required to support SPF and SENDERID. I see this as one of those things of an aged document drafted 4-5 years ago at the time where SPF was viewed as a competitive solution to DKIM and mentioning SPF or giving it credit for existing was probably not on editors mind. But today, SPF is real. Domain Hosting sites have tools to support it for the small to mid size market that are using their domain hosting name servers. DKIM should realize its wide presence from a DNS public key standpoint, not in a How to but to provide insight about the possible conflictive issues and I think its really just about those pesky wildcard DNS feature as Crocker put it. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
MH Michael Hammer (5304) wrote: And this is where I angst. In all the discussions of a broken signature being morally equivalent to unsigned, the thrust has been that it was likely broken in transit. We failed to have the discussion of it being intentionally broken in transit as an attempt to game the system. For header mutations after signing (which are likely to be a malicious attempt in the specific cases we have been discussing) I feel that treating it as simply the same as unsigned is ignoring the potential maliciousness. I recognize what Murray and Dave have said on this point but it grates. The reason we are going through the exercise of creating a stable identifier associated with a signing domain is because we perceive some value whether it be policy associated with the stable identifier or reputation associated with the stable identifier. To simply ignore this and say it is the same as if it wasn't signed is kind of like saying 0=1. I view this from a Fault Analysis standpoint and the first thing to establish are your boundary conditions and it is difficult to have boundary conditions without a policy framework (or process expectations). Part of the modeling do include invalid signatures and we have shown that you can fold many of these invalid signature conditions into a single never signed condition. This why I continue to have a problem with the 4871 policy of transforming an invalid state point to never signed state point. It was fine when POLICY was still part of the framework. When we insisted on separating the two, that 4871 inherent policy should of been removed. This is not the first time, but I would love to re-issue the suggestion to remove that statement from 4871 iff we want to continue to separate policy into another layer. In that case, the higher layer needs all trace information available. The difference is that there is higher weight with deterministic boundary conditions when there is no real signature vs the indeterminate conditions with failed signatures. But depending on the domain expectation, these failed conditions can be folder to the no signature condition. I always come back to an image of an old patented idea of using a perfect circle to represent the optimal boundary conditions for a process. When that circle is skewed, you are off the optimal plane. It may not represent an emergency, but there is a shape or limits that tells you something is not right and alerts need to be signaled. For DKIM, we can only do this with Domain Expectations to help verifiers and local policy be molded. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
Murray S. Kucherawy wrote: There might be a better way to characterize it, but I think the answer comes from the errata RFC upon which we reached consensus a while back: The primary payload delivered by a DKIM validation is the validated domain name. Reputation, for example, would be checked against that, and not against the body hash or some other part of the message. That does not exclude any other functionalities. The claim that it binds elements related to the RFC5322 header fields with the message body is the means of the algorithm, not the end. But the associations are still binding. They are direct associations, especially 5322.FROM hence why author policy is still of interest for the framework (and a WG work product). I think these discussions get a little lost of how applications should be applied. The out of scope Reputation Application is just one of them, but it is not the only one. We got policy to work out at some point and thats a WG item. I posted this a while back but you will have input of various kinds for the various evaluators: DKIM_RESULT= DKIM_VERIFY(MSG) REP_RESULT = DKIM_REPUTATION(DKIM_RESULT, DKIM.D) POLICY_RESULT = DKIM_POLICY(DKIM_RESULT, MSG.FROM, DKIM.D) But these are not the only ones. You will see Expert System like designs take place or systems with flexible rule based scripting available to allow for local policy to be molded. For example, an expert rule can be: if a signature fails and has TESTING flag enabled, then see if he stilling testing after __12__ months then if so, negative classify this signer domain. I indicated a long time ago that we be careful with t=y flag and add guidelines track the usage. It was added. Note, I think the focus with signer domain is fine for trust but it must be recognize that there are other associations and efforts to minimize it, I don't think will be well accepted to the layman market place. Most will see what they see and DKIM signatures are passive extra information. All I like to distinguish is that attempting to only extract the valid signer domain as good useful information must be mirrored with its faults. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
John Levine wrote: By the way, has everyone tested their signing code to see what happens if there's no From: header at all? Do we even agree what the right thing is? I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. For our DKIM implementation, it will fail to sign and fail to verify. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
Steve Atkins wrote: I'd think it'd be approximately the same as if the private signing key (the only other mandatory input I can think of at the moment) wasn't present. If it fails, it's broken, I think. There's nothing special about the From field, other than it having to be one of the signed headers. The spec says 5.4. Determine the Header Fields to Sign The From header field MUST be signed (that is, included in the h= tag of the resulting DKIM-Signature header field). That means to me it MUST exist to be signed. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Issue: 4871bis - section 5.4/5.5 clarify 5322.From requirement
Steve Atkins wrote: Hector wrote: The spec says 5.4. Determine the Header Fields to Sign The From header field MUST be signed (that is, included in the h= tag of the resulting DKIM-Signature header field). That means to me it MUST exist to be signed. h=From for a message that has no From: header when signed means that the message must have no From: header when the signature is validated, I think? And 5.4 just says you must include From in the h= tag, not that it must exist. A missing From: field makes the message not a 5322 message, but I'm not sure what that implies for DKIM. I see your point. Since a 5322.From is a required header for a valid RFC5322 message (From and Date are the two that required by RFC2822 and RFC5322, for RFC822, it requires the To (or BC) as well), I believe the expectation that it exist in the message for DKIM to imply it must exist in h=From. For our MDA/MSA, it will definitely invalidate an incoming message header but I don't recall the details. From old discussions in IETF-SMTP, I am pretty sure most MDA/MSA will enforce a 5322.From as well. I think the exception if when the client is local (internal) or maybe authenticated. The Alt-N DKIM API we are using will definitely fail to sign the message if a From is missing and it will fail to verify as well because there has to be a h=from and matching 5322.From. This probably means that it should clarified what that 5.4 sentence means and also the next section 5.5 5.5. Recommended Signature Content .. The following header fields SHOULD be included in the signature, if they are present in the message being signed: o From (REQUIRED in all signatures) It reads to me that From is the SHOULD exception to a MUST. But I can definitely see what you mean, because if it means that you have to add h=from without a real 5322.From, then a signature might be signed and be technical DKIM valid but only against those systems that are not enforcing a 5322.from header. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
SM wrote: That text adds a requirement in an informative note. My proposal to add more informative notes to help minimize this for the systems with the lack of DNS admin expertise on board. In particular for those with currently one existing need for a TXT record and that is SPF and incorrectly believe since its a TXT record, adding the DKIM public key data to it will work. There is an assumption that people managing DNS zones will have a basic understanding of DNS. I don't think that the DKIM specification should get into badly designed GUIs. RFC 4871 discusses about DNS in various sections. Unfortunately, there is no reference to the DNS specifications. I don't think I am suggesting to get into the bad DNS managements tools. But the section is short on what are possible error issues. One of them is making sure other TXT records don't conflict. I think that can be a general, generic statement that does not get into poor DNS management tools implementation. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Alessandro Vesely wrote: Correct. And the way that it fails to verify is h=from:from. The only way that DKIM can consistently account for this exploit is by amending section 5.5 Recommended Signature Content, and spell what fields MUST/SHOULD be duplicated in the h= tag. -0.5. This is a kludge. Its good to help, possibly, existing systems that is capable of defining the N+1 h=from values in their setup. The problem is you don't know if they can. The real solution is to fix up section 5.4 general paragraph regarding signing and verifying the last header because it ignored the exception in regards to 5322.From which fundamentally there can only be one. It needs to add the exception clause to that paragraph or in a follow up paragraph. Both verifiers and signers MUST make sure its DKIM input, especially the headers it will bind, are technically correct. Only DKIM can do that to close legacy loopholes. The h=from:from kludge should be seen as a temporary solution until verifiers and signers catch up with the Double From problem. It can't depend on other mail bots to do this. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
Barry Leiba wrote: On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote: At 17:31 13-10-10, Hector Santos wrote: My proposal to add more informative notes to help minimize this for the systems with the lack of DNS admin expertise on board. In particular for those with currently one existing need for a TXT record and that is SPF and incorrectly believe since its a TXT record, adding the DKIM public key data to it will work. There is an assumption that people managing DNS zones will have a basic understanding of DNS. �I don't think that the DKIM specification should get into badly designed GUIs. I agree, more generally, that the DKIM spec can't tell people the right way to manage their DNS records. DKIM already separates its TXT records with the _domainkey identifier, as SPF does with _spf. If, given that separation, people still merge the TXT records and whatnot, that problem's well beyond the scope of our work to fix. I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. I know you realize I was not advocating information on managing DNS records. But what happen today, is further evidence that even DNS administrators or software developers who are asked to write a WEB-BASED manager for their service to support SPF and now DKIM, are not aware of how mixing it is can be in conflict. All I ask is that possible a simple statement or sentence in that short section provide some insight regarding not mixing it up with other TXT records and that wildcards should not be used for other TXT records because this can fail the DKIM public key lookup. In this case, a customer is using Network Solutions and in their add TXT record, it doesn't allow a blank sub domain. The only way to do it is to have a subdomain: * (ALL OTHERS) domain: .xyz.com value: v=spf1 . Clearly, this a software bug and the customer called NS about how to get a non-wildcard SPF record because it was interfering with their new DKIM public and ADSP records setup. NS's (first level support) answer was (erroneous) - not possible. It doesn't work that way. So sure, this has to be fixed by NS, but what I am saying is that ISP people will also be reading the specs too perhaps to see what is required to implement Web-based DNS Records Management tools with DKIM and SPF support and what I am proposing is helpful insight on the design guidelines that would avoid conflicts. BTW, the customer (a government newsletter bulk spammer) had to delete his SPF record to get our DKIM implementation running with verifiable signatures. With the conflict, they were getting dkim invalid signatures with selector DNS errors. I'm sure they will be many customers who may not want to delete their SPF record in order to get DKIM working. So my suggestion is to help avoid these potential conflicts. It is not about going deep into DNS management issues. Just the basic DKIM public key integration issues with existing TXT records. If you don't think that is possible, ok. I think it is, but... :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
Scott Kitterman wrote: +1. Just as a note of clarification, SPF doesn't prefix TXT records, but I don't think that affects the analysis. The Network Solutions DNS Records manager does not allow you to add a TXT record without a sub-domain, so to add one, you have to add * which when saved, it shows up as * (All Others) for the sub-domain column. For the new DKIM customer, we were assisting in adding the DKIM public key and ADSP records and this conflicted with the lookups return SPF records for all DKIM/ADSP record queries. Clearly, this is a problem with Network Solutions web tool. What I proposing is provide insight into potential conflicts with existing SPF (or other records) that might have a wild card associated with it. The audience will include ISPs that need guidelines as well and already have a SPF wizard or something or only allow * sub-domains to get a non-prefix domain query. These notes will help provide them and future implementations of DKIM DNS records support the insight to do it correctly. I hope DKIM is about catering to all sites small to large, not just large systems with DBA and DNS administrators. The insights should help adoptions without pains. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
Barry Leiba wrote: On Thu, Oct 14, 2010 at 12:45 AM, SM s...@resistor.net wrote: At 17:31 13-10-10, Hector Santos wrote: My proposal to add more informative notes to help minimize this for the systems with the lack of DNS admin expertise on board. In particular for those with currently one existing need for a TXT record and that is SPF and incorrectly believe since its a TXT record, adding the DKIM public key data to it will work. There is an assumption that people managing DNS zones will have a basic understanding of DNS. �I don't think that the DKIM specification should get into badly designed GUIs. I agree, more generally, that the DKIM spec can't tell people the right way to manage their DNS records. DKIM already separates its TXT records with the _domainkey identifier, as SPF does with _spf. If, given that separation, people still merge the TXT records and whatnot, that problem's well beyond the scope of our work to fix. I appreciate the desire to put more information in there to help, but we really can't be writing a tutorial on managing DNS records. I missed your statement above: ... as SPF does with _spf. SPF is a no prefix lookup. This is why it became a conflict because its possible domains are using wildcards and in at least in one case discovered today, Network Solutions does not allow you to add a TXT record without a sub-domain. You have to get around it with an asterisk (*) and it shows it as All Others. Maybe related, but I have not checked, does 4871 talk about parsing multiple records looking for the v=DKIM1 string? If not, then this is needs to be written about because if we don't want to see anything about wildcard SPF records, then we have implementations that will need to change their wares to only parse the v=DKIM1 string. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] 2 Day Collection Stats
This is a small 2 days collection break down of the signed mail coming in: - total msgs :67028 - dkim_sign : 1779 (2.7% signed) - dkim_pass : 89.9% - dkim_fail : 10.1% --25.9% : dkim_body_hash_mismatch --14.0% : dkim_signature_bad --37.6% : dkim_signature_bad_but_testing --15.2% : dkim_selector_dns_perm_failure -- 2.8% : dkim_selector_invalid -- 4.5% : dkim_selector_granularity_mismatch - ADSP domains: 10.7% (of the signed messages) --38.5% : unknown (78.2% Third Party) --61.5% : all (13.3% Third Party) -- 0.0% : discardable I should probably add a recording which of these has List-IDs, but I think the high body hash failures are most list systems. Its interesting to see such a high selector failure. I think the 2.8% invalid selector has to do with mix ups with SPF records. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
+1. Barry, as the original issue submitter and I only provided suggested text to jump start WG input with better text, I am very happy with Jim Fenton's text. It doesn't lay blame and straight to the key points. Folks, this is really a simple solution and in my opinion, DKIM can gain from this issue resolution with a powerful new marketing angle in how DKIM raises the bar for Email Compliancy to further protect against current spoofing and phishing of user mail agents than any other email technology since the annals of electronic mail. This is something that I can add to my technical marketing of DKIM for our customers. It provides a payoff for customers to support DKIM and to upgrade their software to further harden it. A win win for all. Thanks Jim for stepping in and providing excellent text I hope everyone can compromise and agree with. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Jim Fenton wrote: On 10/12/10 7:58 PM, Murray S. Kucherawy wrote: You're right, it's not limited to From:, but 8.14 only uses that as an example. It does also contain a more general description of the issue. If the diff from RFC4871 doesn't say the right thing, can you propose alternate text? Here's some text I propose for section 8.14, in place of the current text. Bear in mind that this is in the context of the Security Considerations section of the spec, so it is really a discussion of the threat and how it is dealt with, rather than normative text. I went back and looked at the corrected text Dave Crocker sent for section 5.3. Most of this is good advice, but section 5.3 is in the context of section 5, Signer Actions, and is therefore the wrong place to add normative language for verifiers. So I have added a new section 6.1.1 that adds the requirement for message syntax checking to verifiers. I'm open to suggestions on the strength of the verification requirement; I made it a SHOULD, but perhaps it should be a MUST. I'm reluctant, however, to point at three sizable specifications and say that the verifier MUST check everything; that sounds like an unverifiable requirement. I'm open to ideas. = 8.14. Attacks Involving Addition of Header Fields Many email implementations do not strictly enforce the message syntax specified in [RFC5322]. One potentially exploitable consequence of this is that an attacker who is capable of modifying a message in transit could insert additional header fields that, if properly placed, could be rendered to the recipient in preference to the originally signed header fields. According to [RFC5322] section 3.6, certain header fields, including From and Subject, MUST appear a maximum of once per message. It is therefore possible for a verifier to detect the insertion and as discussed in Section 6.1.2, DKIM verifiers are expected to return a verification failure when the invalid insertion of signed header fields occurs. Multiple occurrences of other header fields are not similarly constrained. Should the signer wish to render a signature invalid if a particular header field is added, the signer has the option of listing the name of that header field (or an additional instance of it) in the h= value as discussed in Section 3.5. = Suggested update to paragraph 2 of section 5.3: Similarly, a message not compliant with [RFC5322], [RFC2045], and [RFC2047] can be subject to attempts by intermediaries to correct or interpret such content. See the Section 8 of [RFC4409] for examples of changes that are commonly made. Such corrections may break DKIM signatures or have other undesirable effects. Therefore, a DKIM signer SHOULD confirm that a message is compliant with those specifications prior to processing. /t = Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.): 6.1.1 Validate the Message Syntax The verifier SHOULD meticulously validate the format of the message being verified against the requirements specified in [RFC5322], [RFC2045], and [RFC2047]. In particular, limitations on the number of occurrences of particular header fields specified in [RFC5322] section 3.6 SHOULD be verified. Messages found to be in violation of these checks MUST return a PERMFAIL (message syntax error) verification result. -Jim ___ 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] Collected data
Jim Fenton wrote: It also adds more complexity to the specification and to implementations. Besides, DK compatibility should become less of an issue with time since it is a legacy protocol. +1 IMO, DKIM is already a complex technology to properly implement and integrate into a system, especially with key management. We decided not to deal with DomainKeys. We don't add it or verify it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
Folks, I know section 3.6.2.1 has this informative note: INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g., *.bar._domainkey.example.com) do not make sense in this context and should not be used. Note also that wildcards within domains (e.g., s._domainkey.*.example.com) are not supported by the DNS. But I think the section may need information about working with multiple or existing TXT records, i.e. SPF and the possibility that there could be a wildcard for other TXT records and this can provide a lookup error for DKIM public key records. This is just to jump start suggested text. Others can add/change whether they think helps: The DKIM public key TXT record MUST not be mixed or merged with other TXT records, i.e. SPF. In addition, make sure other TXT records with Wildcards do not conflict with DKIM public key lookups. Background reason: Today we got our 3rd field testers who ran into mixed up TXT records. All of them manage their DNS setup with ISP web based DNS managers for their small business but they are not DNS administrators. They did not understand how the DKIM public key TXT record is separate from other TXT records, like SPF. Two of them merged it with their existing SPF record and one of them had a wildcard SPF setup and this was always the result of DKIM public key lookups. When informed of this, he removed the wildcard setup for SPF but he merged his DKIM public key with his SPF record. My proposal to add more informative notes to help minimize this for the systems with the lack of DNS admin expertise on board. In particular for those with currently one existing need for a TXT record and that is SPF and incorrectly believe since its a TXT record, adding the DKIM public key data to it will work. Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
+1, well said Mark. Its a real potential situation that is on par, IMTO, with what the DKIM technology was suppose to help with. It was unfortunate it fell through the cracks during the Threats Analysis RFC 5016 production. If it was realized back then, I don't think anyone would be debating who is the blame and what was needed to be done (written into the RFC 4871 specs). In retrospect, I recall most discussions was around multiple addresses possible in the single 5322.From header and how to deal with that, especially in regards to redundant POLICY lookups. If I recall, the consensus was that only the first address in the potetial list of from addresses in the single 5322.From header was the only important author domain for POLICY considerations. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Mark Delany wrote: Murray wrote: My objection isn't so much layering within the software, because I know that gets mushy real quick, but layering among the protocol specifications. For example, we wouldn't include in an SMTP specification some text about dealing with fuzzy TCP implementations, and what people are talking about here makes just as much sense to me. The problem is that I don't think we are really just talking about getting a protocol right from a bits perspective. If DKIM has any value it's that it ultimately affects the user mail experience for the better. Consequently, to remain silent on matters that we know will adversely affect that experience seems contradictory. Similarly to not offer guidance to implementors on the sorts of things they can do to maximize the value of DKIM seems similarly to miss the point. Furthermore, DKIM specifically came into existence to deal with an adversarial environment whereas 821/822 and the like have very specific just get the bits right goals. So guiding verifiers to assume the worst seems consistent with our intent or at least our genesis. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
In the new section 8.14, I believe there is many statements that are hardly true, but subjective and written by someone begging to pass the buck with conflictive arguments. DKIM is part of the SYSTEM, DKIM is NOT the SYSTEM. Lets play fair with all parties. 1) Contradiction Many email implementations do not enforce [RFC5322] with strictness. As discussed in Section 5.3 DKIM processing is predicated on a valid mail message as its input. If DKIM designers knew there were many email implementations with less than strict enforcement and strictness was an requirement, then DKIM started with a problem it ignored to address. Either it was ignorant or poor engineering. Reword this. 2) There is no intent. With the intent of providing a better user experience, many agents tolerate these violations and deliver the message anyway. There is no intent by anyone to allow violations. This isn't a game. People have commercial systems and do not just say Hell, lets not follow rules. There are just things that are not expected just like DKIM didn't expect it. Also keep in mind, many systems do reject or flag bad RFC 822/8222/5322 messages. The issue here is that DKIM was a loophole even against compliant RFC5322 checking systems as the President Obama message shown. Reword this. 3) Philosophical conflictive parenthetical sentence: (This can also be taken as a demonstration that DKIM is not designed to support author validation.) It demonstrated the opposite. Please, DKIM *does not reduce* the long historical power of author of the message in any shape or form. The AUTHOR will always be a powerful part of the message. DKIM does validate the author and this requirement is reaffirmed by its special consideration - the only REQUIRED header binding. Until the 5322.From binding is made optional, it will always continue to be very important. In addition, the statement is protocol inconsistent with other existing and new internet protocols that do and continue to make the author a powerful part of the message. Please STOP trying to disassociate the 5322.From from the long time email message communication between parties. Please remove this Oh by the way.. parenthetical statement. Here is my reworded text. I would not give the How to Exploit. Let the bad guy figure it out. No blaming anyone. 8.14. Attacks Involving Addition of Header Fields Historically, email implementations have been tolerant of less than 100% strict RFC822, RFC2822 and RFC5322 formatted messages. There are certain elements within DKIM predicated on having a valid RFC 5322 messages. For example, a message with a single From: header field is expected and required by DKIM. Having more than one From: header violates Section 3.6 of [RFC5322] and should be rejected or flagged by receiving MTA systems and not passed on to DKIM signing engines. A signer wishing to be resistant to any specific multiple header attacks can include in the signed header field list an additional instance of each field that was present at signing. For example, a proper message with one From: field could be signed using h=From:From:... Because of the way header fields are canonicalized for input to the hash function, this would prevent additional fields from being added, after signing, as this would render the signature invalid. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
bill.ox...@cox.com wrote: 50% of the spam we see is RFC compliant DKIM signed, DKIM isnt the issue in your example its the operator and how they determine reputation Please read what was said. No Signature, Double From --- Trapped/rejected by mipassoc.org DKIM signed Double From Accepted, Resigned by mipassoc.org If mipassoc.org is going to an example of many systems, then we have a unfortunate problem until current systems are updated to prevent the DKIM loophole for what is otherwise RFC5322 checking systems. What it means for most systems that they need to change a model based on this: CHECK DKIM PASS -- ACCEPT CHECK RFC5322 BAD -- REJECT BREAK RESIGN DISTRIBUTE To this: CHECK RFC5322 BAD -- REJECT CHECK DKIM PASS -- ACCEPT BREAK RESIGN DISTRIBUTE -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Example of DKIM bypasses RFC5322 Checking
Ian Eiloart wrote: Hector Santos hsan...@isdg.net wrote: DKIM signed Double From Accepted, Resigned by mipassoc.org Yes, we saw that. No Signature, Double From --- Trapped/rejected by mipassoc.org Really? You tested this? I assumed the message was accepted because it contained a From: header belonging to a list member. Not because it was signed. The list checks the 5321.Mail From address (return path), not the 5322.From. Yes, tested twice. I got a bounce back from the list saying it was waiting moderator approval and it gave me the opportunity to click a URL to cancel the submission. GMAIL imports it the spam box as a NO SUBJECT message because it stripped all headers and recreates its own. You will find this common with many MTA that use a Valid 822 or 2822/5322 detector. Let me try it again... Yup. I created a 5322 message with two 5322.From and no signature: -- ENV-FROM: hsan...@isdg.net ENV-TO: ietf-dkim@mipassoc.org ENV-DATA: From: President Obama ob...@whitehouse.gov Message-ID: 4caa540b.5050605xxxaxds...@isdg.net Date: Mon, 12 Oct 2010 12:24:11 -0400 From: Hector Santos hsan...@isdg.net Subject: Non-signed, double from User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ietf-dkim@mipassoc.org Non-signed, double from -- HLS -- When I put that message in the router outbound spool, the MTA routed it to mipassoc.org and this is the list approval message I just received: -- Received: by winserver.com (Wildcat! SMTP Router v6.3.453.5) for hsan...@isdg.net; Tue, 12 Oct 2010 12:45:33 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=none author.d=mipassoc.org signer.d=mipassoc.org; Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by winserver.com (Wildcat! SMTP v6.3.453.5) with ESMTP id 1159772343; Tue, 12 Oct 2010 12:45:29 -0400 Received: from sbh17.songbird.com (sbh17.songbird.com [127.0.0.1]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o9CGk3pR011186 for hsan...@isdg.net; Tue, 12 Oct 2010 09:46:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mipassoc.org; s=k1; t=1286901968; bh=GkF+Zni/AmU95QUngEpyvADEq+U=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject: From:To:Message-ID:Date:List-Id:Sender; b=TF05IDrPNZZkxMxywTFfz8O/w3Hmr/cE42u5jEXBHMX EYrWHRYjdfdVipu0RZ4kvY8vYtkbsZLHvtqtXdi2cgu16xWxuwltYn/+MmPmEufyu47 GtNzERKTf0Tbp+4Hm8EmjayZI3pP0tlkDrZ+cSkfxwwKOm7EBvF+9xrPlmB1k= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Your message to ietf-dkim awaits moderator approval From: ietf-dkim-boun...@mipassoc.org To: hsan...@isdg.net Message-ID: mailman.2971.1286901961.2420.ietf-d...@mipassoc.org Date: Tue, 12 Oct 2010 09:46:01 -0700 Precedence: bulk X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.9 List-Id: IETF DKIM Discussion List ietf-dkim.mipassoc.org X-List-Administrivia: yes Sender: ietf-dkim-boun...@mipassoc.org Errors-To: ietf-dkim-boun...@mipassoc.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [127.0.0.1]); Tue, 12 Oct 2010 09:46:08 -0700 (PDT) Your mail to 'ietf-dkim' with the subject (no subject) Is being held until the list moderator can review it for approval. The reason it is being held: Message has implicit destination Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://mipassoc.org/mailman/confirm/ietf-dkim/c3ab82450dcdff2c7e15dcfc1748c57f69c4e956 -- So this is to show you that it isn't about a receiving MTA not being compliant with RFC 5322, it is about a DKIM loophole. Thats not to say any component in the integrated mail network is not responsible for RFC5322 checking, but DKIM can not expect everyone to do it right, thus it needs to check for itself. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
The next post with the example DKIM bypass exemplifies the point that it is about DKIM fitting into the system, not the other way around. The current text tries to too hard to pass the buck on other systems when in fact, hate to say it, its about DKIM faults not anyone else. This is especially the case when it states it knows that many email implementations violates RFC5322 and thats simply not true. This offends developers quite frankly. Lets stop rationalization and lets call it for what it is. This issue fell through the (Threat Analysis) crack. If we realized it back in 2005/206 during the TA work, I think it is pretty safe to say we would of closed this loop more above and beyond just simply saying Requires RFC 5322 compliance IMO, it really has nothing to do with user experiences per se, although that might be the end result. Many, if not most, existing systems do already check for valid 822, 2822/5322 messages, especially ones that are blatant as this double 5322.From issue. I'm sure even the better ones missed this one. But many systems also do corrections, like add a missing Date: (a violations) or even a To:. All that does is make sure things are correct. Other systems might not like having a missing Date for example. The point is this is par for the course and DKIM should recognized it to fit into it, not for others to fit into DKIM. -- HLS Barry Leiba wrote: Hector says... If DKIM designers knew there were many email implementations with less than strict enforcement and strictness was an requirement, then DKIM started with a problem it ignored to address. �Either it was ignorant or poor engineering. That's not true at all. It's common and reasonable for newer protocols to tighten things up and require stricter adherence to the older protocols. New features often make it unwise or incorrect to treat earlier requirements loosely. This is one of those cases, and in earlier versions of DKIM work there was certainly wording about requiring valid RFC 2822 (at the time) messages. 2) There is no intent. There is, quite often. It's very often the case that things on the receiving side tolerate malformed messages *specifically* to avoid rejecting more messages than necessary. With the intent of providing a better user experience, is absolutely correct in a great many cases. And we're telling verifiers that when you add DKIM, that tolerance might now be unwise. 3) Philosophical conflictive parenthetical sentence: � (This can also be taken as a �demonstration that DKIM is not designed � �to support author validation.) Yeh, that's the only part I agree on (though not with the reasoning that follows). I'm ambivalent about having that parenthetical statement in there. I'd like to see some consensus about whether to leave it or keep it. Here is my reworded text. I would not give the How to Exploit. Let the bad guy figure it out. �No blaming anyone. -1; I like the wording that's there. I also look at the description of the attack not as helping bad guys, but as giving a clear explanation of what the problem is, so implementers understand the problem, and the difficulty that tolerating multiple instances of single-instance fields can create. Barry, as participant ___ 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] ISSUE: 4871bis-02 - Section 8.14 comments
Sounds like you agree with me. :) Its incomplete security analysis and if you going to touch base with it regarding one attack method you need to take about the others, like I shown here: http://mipassoc.org/pipermail/ietf-dkim/2010q4/014802.html This shows its not only a matter of bad messages, but also bypassing existing RFC 5322 checking. Is this not important? It clearly shows that DKIM needs to check its own DKIM requirements and not rely on other layer. Verification is not even mentioned in this new section. Why not? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Dave CROCKER wrote: On 10/11/2010 3:05 PM, Wietse Venema wrote: If you believe that sending mail with a valid bad guy signature is an interesting attack on DKIM, then that implies that you're willing to believe mail that is signed by arbitrary strangers. Well... But it's not an attack on DKIM. It's not really an 'attack' on anything, but the most one could claim is that it's an attack on the recipient's reputation data base, or failure to use one. The DKIM part is used correctly and works fine. So there's no 'attack'. Thats poster framing material. I sure hope you are right. After all, President Obama did get by your defenses on your list. No Signature, Double From --- Trapped/rejected by mipassoc.org DKIM signed Double From Accepted, Resigned by mipassoc.org So without DKIM, 100% RFC5322 compliant - trapped multiple 5322.From headers. With DKIM, there is a loophole. Go figure. Lets hope this DKIM exploit does not become common place and surprises a bunch of layman operators. At the point, you can say you were aware about it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John R. Levine wrote: So here's a 0th cut at a list of headers where we should recommend N+1 entries in the h= rfc 5322 From Sender Reply-To (maybe not, since often smashed by mailing lists) To Cc(not Bcc even though it's 0/1) Message-ID Subject Date rfc 4021 MIME-Version Content-Type I would focus on the main rendering items, the ones common across the mail universe of devices, gated systems, etc. From:required by 822/2822/5322 Date:required by 822/2822/5322 Subject: optional 822/2822/5322 To: required by 822, optional 2822/5322 The others are related to Network Control Lines and are generally hidden and only the ones necessary for a reply (if different than the From) may be kludged in. I know this is old school but it still applies today. Many systems do a Valid Header check in order to see if a header block needs to be generated. This is what allows a human or simple mail bot (print, fax job, etc) to enter no headers in a DATA state and still get mail through because the fields can be filled: From:--- 5321.MAIL FROM To: --- 5321.RCPT TO Date:--- Local Computer Timestamp Subject: --- left blank or filled with (NO SUBJECT) That said I don't see incentives to spoof: Message-ID MIME-Version Content-Type What are the gains? The Sender: can change too, like in a list. Not sure about CC: I guess it should be included. I think for 4871bis, we should keep it simple with focusing on the main security hole, 5322.From (and also make a statement that regarding RFC5322). -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
John R. Levine wrote: I don't see incentives to spoof: MIME-Version Content-Type What are the gains? This has been discussed at great length. Please consult the list archives. Thanks - you couldn't summarize or its too hard to explain? I can search, certainly not consult. But let me consult GOOGLE: MIME-Version Exploits IETF-DKIM Without going nuts looking all the results, I see whats in 4871 section 8.1.1. Addition of New MIME Parts to Multipart/* and this seems about the l= body size issue which most people already agreed is a bad idea. I don't see how the 5322.Mime-Version header can be exploited. Anyway, never mind. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Michael Thomas wrote: On 10/07/2010 05:01 PM, John R. Levine wrote: Nobody has signed a non-compliant message, so while there is nothing wrong with Mike's advice, it completely misses the point. You're right, it does miss the point. What I'm trying to get my head around is whether this is a real problem in the real world. Not yet, but this has a higher risk of occurrence in the future than let's say, SHA1 exploits which required us to incorporate SHA256 into the options mix. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Wietse Venema wrote: With this signer-side configuration solution, the verifier can detect attempts to spoof any header that was covered by the DKIM signature (spoof as in add a forged header, and hope that naive programs will use the forged header instead of the authentic one). So the solution is already available in DKIM. We just need to use the solution, and make it part of routine DKIM tests. Having the signer put the extra junk in h= should make existing verifiers do the right thing, although I doubt the bit of verification code that checks for the non-existence of the N+1st header for N0 is well tested in DKIM implementations. To address this, make this solution part of routine DKIM test suites. +1, however. This is only part of the solution. A temporary one to allow current operators to cover themselves using their Required Header configuration, if any. The real solution is to void double 5322.From messages. Either the DKIM compliant MSA, MDA do it or the better DKIM signer/verification engine does it to cover for legacy MSA, MDA or to make sure customers using a 3rd party signing engine are sending the proper mail to sign. Can someone come up with IETF amenable copy text for Dave to add to 4871bis that won't prohibit or slow it down its progress? IMV, all would be implementers need to read is a basic idea of: Make sure there are no two or more 5322.From headers when signing or verifying. These messages should be voided. and thats it. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
#- I wanted to ability to always have the List-ID to handle both type of streams, private email and list email with one default setup. It would also help to protect against replay by a foreign list server. What I can do now with our setup is change the default to: RequiredHeaders = From:From:To:Date:Message-Id:Organization:Subject:List-ID So the kludge idea is good, but we don't know if most other DKIM application implementations offer this. I believe Levine is correct on this point that most implementations may not be this flexible. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Scott Kitterman wrote: Murray S. Kucherawy wrote: Doesn't DKIM try to detect modification of the portion covered by the hashes, which is unchanged in this scenario? For what I view as a very abstract definition of unchanged, sure. I think adding additional From or Subject does change the content of the message From or Subject. If one takes the view that we've defined things such that this is OK from a protocol definition perspective, so it's not an issue, I think we've lost sight of the original goal of this requirement in the protocol. I think that this can be dealt with through an additional security consideration and doesn't have to disrupt the rush to get this advanced through the standards process. +1. Well, then again, one side of my is trying to be cooperative and sensitive of those who want to rush the document. Minimize text with not saying too much. But the other side is saying technically Fix this ASAP - get the proper protocol semantics in in the 4871bis specs and use this incident or at least prepare a response ready against any negative PR that could emerge as a plus to enhancing the marketability of DKIM as a tool that helps solved a 25+ year old problem. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Inadvertent Spoof
Jeff Macdonald wrote: Hence my original post with the suggested special consideration text for section 5.4 in regards to 5322.from. -- My apology to Jeff. It was not Jeff Macdonald who wrote the text above. This was not an attempt at a spoof. I somehow replied to the wrong message and my MUA (ThunderBird) somehow used the wrong From: address with the text I was writing. My Apology to Jeff. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Michael Thomas wrote: On 10/07/2010 03:40 AM, Charles Lindsey wrote: On Wed, 06 Oct 2010 13:00:25 +0100, Steve Atkinsst...@wordtothewise.com wrote: On Oct 6, 2010, at 1:47 AM, Mark Delany wrote: Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. To comply with that MUST every DKIM verifier would have to include a full 5322 verifier. That's a fairly high bar. No, that is not true, as I have demonstrated in the text I have proposed. You only need to look at whatever headers are actually mentioned in the h= tag of the signature, and you only need to verify those properties of those headers that could lead to trouble, and that would seem to be a simple count of the number of occurrences of those headers. I'm with Steve on this one. Forcing implementations of DKIM to determine whether a message is compliant is a pretty high bar. I for one wouldn't be in any particular big hurry to add a batch of code to insure that that MUST was fulfilled. I doubt anyone else would be either. The net effect of this MUST would be to make a lot of compliant DKIM implementations non-compliant. And for what? I'd say that it would be better to just say that if you sign a non-compliant 5322 message that its verification is undefined, and move on. That at least matches reality, and hasn't hurt anything that I'm aware of. This is a half full, half empty issue. Lets look at the positive side. DKIM by its very nature has already raised the bar of legacy mail by adding a new level of considerations that mandates certain parts, especially the 5322.From (since its the only requirement for hashing), be valid. We never (afaik) had any technology that does this at the MTA level. DKIM serves that purpose, thus the beauty of it. Before DKIM, RFC5322 has this major problem today. DKIM can leverage this RFC5322 vulnerability by helping address attention to it and close the loophole. It does raise the bar for wannabe DKIM compliant systems to do more than what is normally done. A implicit presumption that mail is RFC5322 compliant is not a safe presumption. The beauty of DKIM is that it moves us away from the legacy system exploits - by raising the email compliancy bar. In that vain this multiple 5322.From issue is directly related to a DKIM purpose to secure it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Michael Thomas wrote: Generally I agree, but does saying verification is undefined satisfy those concerned that this is a security vulnerability? The example of double-From: shows verification succeeds. It's the interpretation of those results that is the problem. These are two separate questions, I think. I'm only commenting on whether DKIM should be the SMTP police. I don't think so, but it should inspect its own protocol requirements and within those requirements is its crown jewel - 5322.FROM, the only header that is required binding. Now lets consider if its wasn't a requirement, would it matter then? I think it greatly matters to the MUA participants. Note, the 5322.Subject is also a victim here, but its optional and its security threat is not even close that what a multiple 5322.From reveals. So I think it warrants adding a check for that too. But not as much as the From. The point is DKIM took on the job of providing a mail integrity and authentication work and raised the about what is expected. Included in that job is protecting its primary header - 5322.From. Keep in mind that not protecting it will also hurt ADSP which I already showed that implementation may look for the first one as well. In the spoofed Obama message, this is the authentication results generated here: Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=none author.d=whitehouse.gov signer.d=mipassoc.org; It picked up the wrong one. So we have TWO protocols that are affected by this. The irony in all this is that this Multiple 5322.From could be used to solve the MLM 3rd party issue. :) The verifier MUST check for invalid 5322.From messages if only because its part of the DKIM and ADSP formula and mechanics. Anyway, I hope the right decision is made and address it before it widely discovered and becomes a problem. Even without DKIM, MTA should be more aware about this and deal with it. But only DKIM can close the loophole for legacy operations. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Mark Delany wrote: That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. Agreed. Though frankly I couldn't care less about signers. It's always the verifier that really counts. I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. +1. However, the rat hole is when we are not specific and leave it open ended. The proposed text can be: Verifiers MUST make sure only check valid RFC 5322 messages are verified. Specifically verifiers MUST check for multiple 5322.From headers in the message and if found, the verifier MUST invalidate the signature [and reject|discard the message]. If we remain focus with this specific issue on hand - multiple 5322.From, which is critical in the mail infrastructure in every network and is used for every Online or Offline MUA, and today related to DKIM with the required 5322.From hashing, this is one specific invalid mail case that can be easily addressed and doesn't have to be a rat hole nor delay 4871bis progress to draft standard. The funny thing is, I am not even a hacker and I was able to take an archived 5322 message text file, prepend a 5322.From line and resubmit back into the stream with perfect DKIM validity and resigning by another MTA/MLM. It was too easy and I am not smart enough to determine what real hackers can imagine to come up with. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Charles Lindsey wrote: On Mon, 04 Oct 2010 23:24:11 +0100, President Obama ob...@whitehouse.gov wrote: THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE Interestingly, my MUA (Opera) displayed both of those From headers, But I can quite well understand that many other MUAs don't, and even where they do I would expect many phishees would not notice the second one. Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=none author.d=whitehouse.gov signer.d=mipassoc.org; And for ADSP, our verifier picked up the first (top) 5322.From domain as well. Since I whitelist mipassoc.org, I get all its output. Mind you, that I had to do this twice to get a copy because I had already added a multiple 5322.From rejector script at the SMTP DATA session. I had to turn it off and repeat it to get a copy that I see here from spoofed President Obama. So the 5321/5322 filtering layer approach works fine (but we lose interesting mail g). But I would not have done this if I was not made aware of this problem by Alt-N who discovered this security hole. And that is the main gist of this, and I don't care how the IETF cats wants to do this: Engineering AWARENESS must be added to the 4871bis. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Dave CROCKER d...@dcrocker.net wrote: In particular, it makes the multiple From: issue entirely irrelevant to DKIM. Scott Kitterman wrote: In a normative sense, perhaps, but in real world terms, it doesn't. Since this does away with It's not valid 5322, so it can't be valid DKIM, it puts the question of how implementors should deal with such things back on the table. +1 I'd like to see us include a general helpful note to implementors about covering the case where a duplicate header field is added after signing. Maybe this is an added item for security considerations? +1. This is where I thought it would go. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: implementation Report v02 - Removal of 1st vs 3rd party statistics
Ian Eiloart wrote: -1 It is extremely relevant. The data is there. The numbers can be calculated from the sample size (~500k) and the proportions. They're nowhere near the numbers (Originator signatures: 1.2 billion Third-party signatures: 184 million) that you quoted in another email, which also don't match the proportions that you quoted. Where did 1.2 billion come from? Sounds like revision v02 is already having its intended effect. Ian, see the previous revision v01 section 4.2 http://tools.ietf.org/html/draft-ietf-dkim-implementation-report-01#section-4.2 In fact, what was left in rev 02 was Murry's 78.9% for the OpenDKIM observation of 1st vs 3rd. What was removed was the AOL data point. I stated it as 86% here: http://mipassoc.org/pipermail/ietf-dkim/2010q3/014556.html Third party is somewhat of a leap from the domains don't match. Third party per RFC 5016 is well defined. For example, if the from header is in the domain example.com and we see d=foo.example.com, is that really a third party signature? Perhaps some clarity of whether subdomains were permitted to match would be useful.* It doesn't matter. The Observed data is what counts. Per RFC 5016 definitions, this is what we got X for that, Y for this. Oh, and are you thinking this is about implementation of ADSP? As an engineer I look at data, look for patterns, see how they correlate to logical protocols and even justify experiments and problem solving. To me, the data points show there is a strong 1st party stream of mail. POLICY would be important here. But that is not what the report is about. For example, if the report showed the opposite, over 70% of the mail stream was 3rd party (5322.From != DKIM.d per RFC 5016), rest assured, we would be hearing how much POLICY or ADSP is insignificant and should be deprecated - and I would AGREE. The reality is the overwhelming 1st party mail continues to justify a need for policy. But that is my interpretation, not what the report is about. I think it's supposed to be about implementation of DKIM, so that DKIM can be progressed. Please don't let a misunderstanding hold that process up. Its not an mis-understanding. There is nothing holding back DKIM but this constant interference with the reality. Embrace and see how things change. What the factoid removal does is goes against chartered itemize goals of #2, #3 and #4. * It would be interesting to know what proportions of author addresses were subdomains of the d= value, and vice-versa. Even to know if the domains share common whois registrations (like foo.example.com and bar.example.com) would be nice, though harder to do. Having said all that, I have my own log files that I could analyze, so I'll shut up. Your, all data would be welcomed too. Soon I will have accumulated data as well. Currently working out how to present them in our web-view of the statistics. IOW, adding DKIM/POLICY related columns to these statistics: http://www.winserver.com/public/spamstats.wct -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Julian Mehnle wrote: Hector Santos wrote: It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. No. The trick is to list From twice in h=. This ensures more From headers cannot be added without breaking the signature. Julian, this was explored and it does not matter. You can add N number of h=from: and N+1 is all that is needed in the security hole. Perhaps this could be mentioned in the spec with a specific reference to the From header, but in general terms the spec is pretty clear about how to prevent the addition of a header field. If you referring having duplicate from: in h= mitigate this issue, see above. As I proposed, the semantics must include an exception clause for the Verifier and Signer signing 5322.From binding logic as described in section 5.4 to address this. It also needs to recommend that MTAs do RFC5322 validating as well - but you are not going to find this in the wild unless the MTA is DKIM compliant and is aware of this situation. It has to be documented in 4871bis for DKIM standardization to make implementations now and the future aware of it and deal with it. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Ian Eiloart wrote: --On 4 October 2010 18:24:11 -0400 Hector Santos hsan...@isdg.net wrote: It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to display the signed header? Are there really MUA's that will display the unsigned headers *and* assert that it was validated? If so, that's surely a bug in the implementation of the MUA. Ian, it would be not practical to expect MUAs to address this. But sure a recommendation for MTAs and MUA to validate RFC522 specifically in regards to 5322.From would suffice. As Keith Moore recently stated in IETF-822: Okay, I'll state it with more precision: The checking of headers should only occur when such a feature is actually being used: e.g. when the message is actually being submitted, being filtered for spam specifically on behalf of a sender or recipient, or being gatewayed into (or out of) a foreign (non-Internet) mail system. His point, in IMV, is that you are not going to find many MTA doing RFC 822/2822/5322 checking unless it has a specific purpose. A DKIM ready ADMD or MTA receiver might be able to reject/drop invalid mail with multiple 5322.From lines. We added a script for this ourselves. But to cover all loopholes the DKIM-verifier MUST have an additional requirement to fault a message with 2 or more 5322.From lines. That is exactly what the ALT-N open source DKIM/ADSP API did - added an additional requirement for DKIM verification that is above and beyond what the current specs says and currently allows. The whole point of a BIS is to help codify the implementation field testing and experiences which alter or fine tunes the proposed draft protocol. This one chalks up as on par with what we are seeking. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Julian Mehnle wrote: Hector Santos wrote: Julian Mehnle wrote: The trick is to list From twice in h=. This ensures more From headers cannot be added without breaking the signature. Julian, this was explored and it does not matter. You can add N number of h=from: and N+1 is all that is needed in the security hole. I don't get what you're saying. I interpret RFC 4871, section 5.4 (actually, exactly the part you quoted originally), such that signing a message that has a dingle From field with h=From:From ensures that adding another From field will break the signature. If you're saying there is a way to add a second From field a message thusly signed without breaking the signature, could you please explain to me how? You are correct. Adding a second from: to the h= tag: h=from:from:.. can address this. But no implementation does that. Instead the ALT-N open source code library counts the 2nd in the verification process and invalidates the signature. My earlier response to you got mixed up with SIGNING test cases where there was multiple 5322.From and multiple from: adding to the h=. Example: From: --- Injected, Replayed and MUA Display From: --- satisfy 2rd hash binding DKIM-Signature: h=from:from: From: --- satisfy 1rd hash binding and EXPECTED MUA Display So you have N number of h=from SIGNER binding, and you need N+1 to exploit it in the VERIFICATION. Of course, you would have violate 5322 in the first place to have a 2nd bound 5322.From. So no good guy will do this. But bad guys will see your typical single 5322.From and one from: in the h= tag. Either way, there is a security issue and a new requirement to secure it either with your suggestion or changes to the guidelines to check for this exception. Obviously, the ease of this exploit is a concern. Any high value domain mail can now be found and replayed with a phished or spooked 2nd or more 5322.From: -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] signing and verifying invalid messages
Michael Thomas wrote: On 10/05/2010 01:36 PM, John Levine wrote: Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. Would it be a good idea to recommend in 4871bis that DKIM implementations should not sign or verify invalid messages? I cheerfully admit that I haven't thought out all the implications thereof. I'd suggest that it would be better to take that up with rfc5822-bis since this is hardly a dkim-specific problem. In my engineering opinion, it was a security hole that fell through the cracks during the development of the RFC 4886 Threat Analysis. If it was presented back then, we would be dealing with the semantics as I propose to deal with it simply because we can't ignore it or blame RFC 822/2822/5322 implementation or MUAs. This is a DKIM issue and it needs to get addressed. Any system today that displays: signed by: but displays a spoofed 2nd From can produce a major confidence problem for DKIM. I have a problem understanding the blow back to the security issue. 4871bis is active. Something needs to be added to 4871bist so that implementations and operators are made aware of it, now and into the future. I highly recommend that the key editors embrace this and deal with it or risk negative DKIM public relations if this gets into the media or into the mind set of any hackers and potential DKIM exploiters. You need to deal with it. Not ignore it or pass the buck to other layers of email. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com [1] http://tools.ietf.org/html/rfc4686 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Julian Mehnle wrote: President Obama wrote: [...] Funny, but this shows nothing because mipassoc.org resigns messages (d=mipassoc.org). (Oh, and it even included *two* Froms in h= on your message.) Right. Does this add signer reputation weight for the injected 5322.From? Not good. If mipassoc.org is being vouched by some 3rd party reputation service. The user sees a signed valid message possibly vouched by trusted service with a signature hash bound spoofed 5322.From. I propose the following addition text by adding to 48721bis to address this serious issue; Special Consideration for Verifying and Signing From: Header As an exception, header hash verification MUST be done for all 5322.From fields and not just the last one. Signing MUST be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. This will mitigate any replay that prepends a new 5322.From header to a DKIM signature valid message. Some MUAs have shown to display only the first 5322.From header found. -1. Why do you insist on changing the hashing semantics to special-case From? Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. Not proposing a to change the semantics. But rather to add insight about the issue so that implementators can deal with it. For example, when I received the echo back from the list, my MTA rejected it. 18:46:07 C: MAIL From:ietf-dkim-boun...@mipassoc.org SIZE=5329 18:46:07 S: 250 ietf-dkim-boun...@mipassoc.org 18:46:07 C: RCPT To:hsan...@isdg.net 18:46:08 S: 250 hsan...@isdg.net... Recipient ok 18:46:08 C: DATA 18:46:08 S: 354 Start mail input; end with CRLF.CRLF 18:46:08 ** end of data received. (bytes: 5738) 18:46:08 ** WCX Process: SmtpFilterHookLoader ret: 0 18:46:08 ** Invalid 5322 Message - multiple From: headers not allowed 18:46:08 S: 551 Message Not Accepted by filter. 18:46:10 C: QUIT 18:46:10 S: 221 closing connection Personally, -1 on suggesting a h=from:from, because you are assuming that operators are actually defining a h= tag. If its blank, its falls back to the semantics written - use the LAST header found. However, if you are suggesting that it needs to be explicitly defined to mitigate this problem, then the specs needs to be updated to address the security issues. The fact, Mipassoc.org, stripped my original header and signed with the double from: lines, one real, one an injected spoofed, proves exactly what the problem here is. I would not be surprised if testing this with gmail.com shows the same thing which the online gmail MUA will have an indicator: signed by: some signer domain but will it display the injected spoofed unbounded 5322.From? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Hector Santos wrote: I would not be surprised if testing this with gmail.com shows the same thing which the online gmail MUA will have an indicator: signed by: some signer domain but will it display the injected spoofed unbounded 5322.From? For the records, from my gmail testing, it will spambox the RFC 5322 message with one or more 5322 lines. But it also does one other thing - it removes ALL the headers and recreates its own with no subject. It doesn't matter if its signed or not. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Julian Mehnle wrote: Hector Santos wrote: Right. Does this add signer reputation weight for the injected 5322.From? Probably not. How do you know what the heuristic systems are doing? AFAICT mipassoc.org doesn't verify DKIM sigs on list messages, it does. It verifies, adds an Authentication-Results: header, strip the original signature, add a fooder and a [list] to the subject and resigns. and even if it did, a verified DKIM sig (such as one created by the original author of the message) doesn't tell anything about the legitimacy of the use of the From identity. Not sure what that means Julian. Personally, -1 on suggesting a h=from:from, because you are assuming that operators are actually defining a h= tag. If its blank, its falls back to the semantics written - use the LAST header found. No. h= must not be empty. The spec explicitly forbids this. You misunderstood. What that means is that the signing function MUST add a h= to the 5322.DKIM-Signature line for the 5322.headers it decides to hash and bind to the signature. The operators with their DKIM implementation can set what headers to sign or they can choose NOTHING and allow the default behavior for the implementation. In other words, the operator can set (in whatever way the software does it): RequiredHeaders From:To:Date:Message-Id:Organization:Subject Now the signing engine will follow this. If not set, then it has its own default rules. The recommendation is presented in RFC 4871. What you are suggestion is that implementation had their defautlt to include From:From, like above: RequiredHeaders From:From:To:Date:Message-Id:Organization:Subject As for a possible change in RFC 4871bis, if you look at page 41 of 4871bis-01 (page 36 in RFC 4871), it already has this nice little note: | INFORMATIVE NOTE: A header field name need only be listed once | more than the actual number of that header field in a message at | the time of signing in order to prevent any further additions. | For example, if there is a single Comments header field at the | time of signing, listing Comments twice in the h= tag is | sufficient to prevent any number of Comments header fields from | being appended; it is not necessary (but is legal) to list | Comments three or more times in the h= tag. I suggest replacing Comments with From. That should solve the problem. I did notice this too and thought the same idea. :) What the specs need in whatever IETF method you guys like to do things: 1) Semantics that DKIM-compliant MTA doing stonger RFC 5322 checking and at a minimum, checking for multiple 5322.From (and possible even 5322.Subject). 2) To close the loophole to #1 (legacy software), the DKIM verifier SHOULD void messages with 5322.From which are not bound to the signature. 3) To close the loophole to #1 (legacy software), the DKIM signer MAY consider adding a h=from:from to the DKIM-Signature. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Stephen Farrell wrote: On 05/10/10 23:54, Julian Mehnle wrote: Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. Assuming that recommending above maps to a (putative) MUST/SHOULD statement in 4871bis, I'd be interested in opinions as to whether such a change might slow progress to draft standard, or be detrimental to current deployments. So in terms of meeting our chartered goals, this specific addition might have undesirable side effects were it to represent the WG's opinion. (Much as the chairs love you all, starting right in on a 4871ter is not attractive:-) To address current implementations, guidelines should be considered: 1) Suggest MTA do stonger RFC 5322 checking and at a minimum, checking for multiple 5322.From (and possible even 5322.Subject). 2) To close the loophole to #1 (legacy software), the DKIM signer MAY consider adding a h=from:from to the DKIM-Signature. 3) To close the loophole to #1 (legacy software), the DKIM verifier SHOULD void messages with 5322.From which are not bound to the signature. #1 is words and a remember for MTA especially those that are with a DKIM environment to tighten up there wares. #2 can be done with current implementation operators. I am assuming all or not most of DKIM signing engines will allow operators to set Required Headers to sign. It would be rather inflexible if it did not. #3 is already done by at least one open source DKIM API developed by a large MTA vendor. Not sure how OpenDKIM is will do it, but Murray did speak of the layer (#1) approach. #1 and #2 will allow most implementations to close this loophole until software vendors catch up with #3. That said, I don't think writing #1, #2 or #3 text for 4871bis should slow down progress to draft standard. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DSN with signature replay
I am wondering or under what scenario would a DSN (bounce) agent keep the original signature in its bounce notification 5322 headers? It was a legitimate bounce for a non-delivery address. But it kept several headers from the original message in the DSN message headers: DKIM-Signature: Organization: X-Mailer: What logic is there to this? Of course, the signature was invalid. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DSN with signature replay
Sonneveld, Rolf wrote: On 04-10-10, *Hector Santos *hsan...@isdg.net wrote: I am wondering or under what scenario would a DSN (bounce) agent keep the original signature in its bounce notification 5322 headers? It was a legitimate bounce for a non-delivery address.� But it kept several headers from the original message in the DSN message headers: ��� DKIM-Signature: ��� Organization: ��� X-Mailer: What logic is there to this? RFC 3462, chapter 2. quote �� The Text/RFC822-Headers body part should contain all the RFC822 http://tools.ietf.org/html/rfc822 �� header lines from the message which caused the report.� The RFC822 http://tools.ietf.org/html/rfc822 �� headers include all lines prior to the blank line in the message. �� They include the MIME-Version and MIME Content-Headers. /quote /rolf The report does contain the original message. I speak of the actual bounce message from the mailer-daemon contain a copy of above headers: DKIM-Signature: d=santronics.com; --- copy Organization: Santronics Software, Inc. --- copy X-Mailer: wcMail v6.3.453.4 --- copy Date: Fri, 01 Oct 2010 09:18:26 -0400 From: mailer-dae...@xx.com To: return-addr...@santronics.com Subject: DELIVERY FAILURE: . The rest of the DSN body message with the message/rfc822 report attachment containing the original message was fine. Am I still missing something? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DSN with signature replay
Very odd. It might be the same software, but what I am seeing is the bouncer doing: 1) Copies the original headers minus Received trace headers, 2) Change From: to the mailer daemon address 3) Change To: to the return path address 3) Adds headers for DSN mime parts. The only reason I am seeing this because we are signing mail now and I'm seeing the new invalid signature logging with these type of bounces. -- HLS Hector Santos wrote: Sonneveld, Rolf wrote: On 04-10-10, *Hector Santos *hsan...@isdg.net wrote: I am wondering or under what scenario would a DSN (bounce) agent keep the original signature in its bounce notification 5322 headers? It was a legitimate bounce for a non-delivery address.� But it kept several headers from the original message in the DSN message headers: ��� DKIM-Signature: ��� Organization: ��� X-Mailer: What logic is there to this? RFC 3462, chapter 2. quote �� The Text/RFC822-Headers body part should contain all the RFC822 http://tools.ietf.org/html/rfc822 �� header lines from the message which caused the report.� The RFC822 http://tools.ietf.org/html/rfc822 �� headers include all lines prior to the blank line in the message. �� They include the MIME-Version and MIME Content-Headers. /quote /rolf The report does contain the original message. I speak of the actual bounce message from the mailer-daemon contain a copy of above headers: DKIM-Signature: d=santronics.com; --- copy Organization: Santronics Software, Inc. --- copy X-Mailer: wcMail v6.3.453.4 --- copy Date: Fri, 01 Oct 2010 09:18:26 -0400 From: mailer-dae...@xx.com To: return-addr...@santronics.com Subject: DELIVERY FAILURE: . The rest of the DSN body message with the message/rfc822 report attachment containing the original message was fine. Am I still missing something? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D Action:draft-ietf-dkim-implementation-report-02.txt
Murray S. Kucherawy wrote: This version makes minor editorial corrections to AOL's data, adds Gmail's data, updates OpenDKIM's data, and applies feedback recently sent to the list. I propose a WGLC on this at the chairs' discretion. I don't have any additional data pending to add, and it sounds like the AD is already happy with the information that's currently there. Wow! SMUDGING OF DATA by removing one of the most significant data points: Author vs. Third-Party: 73% of the signatures observed were author signatures, meaning the d= value in the signature matched the domain found in the From: header field. The remainder, therefore, were third-party signatures. Originator signatures: 1.2 billion Third-party signatures: 184 million Unbelievable! -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Issue: implementation Report v02 - Removal of 1st vs 3rd party statistics
Barry Leiba wrote: Thus begins working group last call on the DKIM implementation and interoperability report, draft-ietf-dkim-implementation-report-02: http://tools.ietf.org/html/draft-ietf-dkim-implementation-report The working group last call will run through Friday, 22 October, 2010. This implementation report will be used to advance the DKIM base spec to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I have only one comment. The removal of very significant data points from this last revision: Author vs. Third-Party: 73% of the signatures observed were author signatures, meaning the d= value in the signature matched the domain found in the From: header field. The remainder, therefore, were third-party signatures. Originator signatures: 1.2 billion Third-party signatures: 184 million This is signification information. Why was it removed? Why hide this significant fact? -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
