Re: [ietf-dkim] The good ol' t= tag in key records
On Wed, Jul 25, 2012 at 10:42 PM, Roland Turner roland.tur...@trustsphere.com wrote: This appears to be the inverse of the use case that was originally put forward (we're concerned that we're signing rubbish, please disregard signatures made with this selector); the very case that you're arguing should be sustained despite t=y (considering negative reputation gained because rubbish is being signed) is exactly the one the ignoring of which started this discussion, no? Pretty much. I wonder whether it would make more sense to view t=y as a holdover from DomainKeys and its o=-; that the need for a testing mode in fact only arose from the need to be able to tread carefully around making a we want some (presumably fraudulent) mail with our name on it blocked assertion. If this view prevails then t=y is merely a vestige that should have been removed when o= was punted to SSP/ASP/ADSP. I'd suggest that the opportunity to remove the (small) complexity represented by a feature that's not solving a useful problem (and has to some extent been superseded by DMARC: if you're not yet confident then stay at p=none) is worth taking. We could, if we ever want to change DKIM again. It sounds like Barry's approach to register a new t= value, or a new tag altogether, is a viable path forward until someone decides to take up the reins and push DKIM to Internet Standard status. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
On 7/23/2012 8:20 AM, Murray S. Kucherawy wrote: On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker d...@dcrocker.net mailto:d...@dcrocker.net wrote: Here are two small tweaks that might correct things: y This domain is testing DKIM. Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email. This covers both successful and failed verification. Verifiers MAY wish to track and report testing mode results to assist the Signer. This isn't quite right, I think. For a signed message that verifies, a negative reputation should still be considered applicable. A positive one should not. That's not equivalent to unsigned. Verification doesn't matter. Again, the current normative text is straightforward and reads: Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email,... That's an absolute. It's does not depend upon whether the signature validated or didn't validate. It says that the processing of the signature is not to affect the handling behavior. All I did with the modifications is to add some brute force assurance that the reader will not misinterpret or miss criteria or implications. The changes do not change the existing semantics. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
That customer brought up an interesting point. t=y could also be useful for messages whose signatures do verify. Specifically, it could be used by a signer to say It's possible this message shouldn't have been signed by us. Please don't give it any preferential treatment based on our name's reputation if the signature verifies, which could then tarnish our reputation. Should't have been signed by us clearly can't mean that someone stole the private key or otherwise hacked things, so you're saying, Our processes might not be set up right, and we might be signing crap sent by bad guys. Give us a break until we get things straight. Any comments about this? I talked to Dave last week as we happened to be at the same event, and he thought this warranted a new erratum against RFC6376. No, it absolutely doesn't, and please don't do that. This was not something that had been considered during the development of 6376, but didn't make it into the document correctly. You might consider that it's something that *should* have been considered, and oops, we blew it... but that's not what the errata system is for. There's a DKIM wiki and issue tracker still available on the former working group's tools page ( http://tools.ietf.org/wg/dkim/ ), and we can change the permissions on the issue tracker if folks want to use that to track these sorts of things for future updates. But more to the point, it seems that this isn't a specific we're testing our system issue, but a separate issue related to reputation: Do not use signatures made with this key as input to your evaluation of our reputation. It would seem best to propose a new tag, in a DKIM extension, for that purpose, rather than re-using and overloading t=. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
On Mon, Jul 23, 2012 at 6:26 AM, Richard Dawe rich.d...@messagesystems.comwrote: Do you think that DMARC provides a better way of testing your DKIM signatures than DKIM's t=y? E.g.: p=none DMARC policy. I don't understand what you're after here. How would a mail receiver apply p=none as different from handling a bad signature? In both cases, delivery is supposed to be unaffected. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
On Mon, Jul 23, 2012 at 6:42 AM, Michael Thomas m...@mtcc.com wrote: There seems like there are many things wrong with this sort of helpfulness. If a given selector is dodgy, the reputation system should figure that out for itself. Believing even a vaguely positive-assertion from the source is almost certainly a mistake, and likely to be gamed if you do. To be precise, the thinking was more Don't ascribe any positive benefit to this message based on our reputation. You could still adjust your reputation of the signer based on the quality of what that domain is signing. It's a voluntary negative-only assertion. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
But more to the point, it seems that this isn't a specific we're testing our system issue, but a separate issue related to reputation: Do not use signatures made with this key as input to your evaluation of our reputation. It would seem best to propose a new tag, in a DKIM extension, for that purpose, rather than re-using and overloading t=. Since RFC6376 ascribes almost no real meaning to t=, what's the harm with revising its definition, perhaps with an Updates draft? What I should have said was overloading t=y, which seems like what you're proposing... and RFC 6376 absolutely ascribes a meaning to t=y: it indicates some sort of testing mode. If you want to do this, you need a new flag (t=r, or some such) or a new tag, and it should be specifically aimed at reputation, not at any sort of testing mode. I don't think Updates 6376 is needed nor appropriate; it's a straight extension. That said, I'm inclined to agree with Mike T that input from the reputation target is suspicious, so it's not clear how much value it will have nor whether it might be gamed (by the reputation target) or hacked (by someone wanting to hurt the target's reputation). Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
On Mon, Jul 23, 2012 at 6:13 AM, Barry Leiba barryle...@computer.orgwrote: Should't have been signed by us clearly can't mean that someone stole the private key or otherwise hacked things, so you're saying, Our processes might not be set up right, and we might be signing crap sent by bad guys. Give us a break until we get things straight. Right. But more to the point, it seems that this isn't a specific we're testing our system issue, but a separate issue related to reputation: Do not use signatures made with this key as input to your evaluation of our reputation. It would seem best to propose a new tag, in a DKIM extension, for that purpose, rather than re-using and overloading t=. Since RFC6376 ascribes almost no real meaning to t=, what's the harm with revising its definition, perhaps with an Updates draft? Otherwise, I'm fine with that path if others are. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
On 7/21/2012 9:50 PM, Murray S. Kucherawy wrote: That customer brought up an interesting point. t=y could also be useful for messages whose signatures do verify. Specifically, it could be used by a signer to say It's possible this message shouldn't have been signed by us. Please don't give it any preferential treatment based on our name's reputation if the signature verifies, which could then tarnish our reputation. When Murray and I talked, I didn't review the existing text. Having just done that: t= Flags, represented as a colon-separated list of names (plain- text; OPTIONAL, default is no flags set). Unrecognized flags MUST be ignored. The defined flags are as follows: y This domain is testing DKIM. Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email, even should the signature fail to verify. Verifiers MAY wish to track testing mode results to assist the Signer. I see that its semantics already cover the case that is being discussed, specifically with the core clause: Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email,... That any reader does not readily see this suggests to me that some clarification language would be useful to apply, as well as an annotation about report. The clarification attempted in the remainder of that sentence appears to cause readers to think that successful verification is excluded! Here are two small tweaks that might correct things: y This domain is testing DKIM. Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email. This covers both successful and failed verification. Verifiers MAY wish to track and report testing mode results to assist the Signer. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
On 07/23/2012 06:47 AM, Murray S. Kucherawy wrote: On Mon, Jul 23, 2012 at 6:42 AM, Michael Thomas m...@mtcc.com mailto:m...@mtcc.com wrote: There seems like there are many things wrong with this sort of helpfulness. If a given selector is dodgy, the reputation system should figure that out for itself. Believing even a vaguely positive-assertion from the source is almost certainly a mistake, and likely to be gamed if you do. To be precise, the thinking was more Don't ascribe any positive benefit to this message based on our reputation. You could still adjust your reputation of the signer based on the quality of what that domain is signing. It's a voluntary negative-only assertion. Yes, I got that. I still think it's a bad idea to pay attention to it as it's very likely that the reputation service will be gamed if it does. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
On 07/23/2012 06:13 AM, Barry Leiba wrote: That customer brought up an interesting point. t=y could also be useful for messages whose signatures do verify. Specifically, it could be used by a signer to say It's possible this message shouldn't have been signed by us. Please don't give it any preferential treatment based on our name's reputation if the signature verifies, which could then tarnish our reputation. But more to the point, it seems that this isn't a specific we're testing our system issue, but a separate issue related to reputation: Do not use signatures made with this key as input to your evaluation of our reputation. It would seem best to propose a new tag, in a DKIM extension, for that purpose, rather than re-using and overloading t=. There seems like there are many things wrong with this sort of helpfulness. If a given selector is dodgy, the reputation system should figure that out for itself. Believing even a vaguely positive-assertion from the source is almost certainly a mistake, and likely to be gamed if you do. Mike Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker d...@dcrocker.net wrote: Here are two small tweaks that might correct things: y This domain is testing DKIM. Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email. This covers both successful and failed verification. Verifiers MAY wish to track and report testing mode results to assist the Signer. This isn't quite right, I think. For a signed message that verifies, a negative reputation should still be considered applicable. A positive one should not. That's not equivalent to unsigned. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
Murray S. Kucherawy wrote: On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker d...@dcrocker.net wrote: Here are two small tweaks that might correct things: y This domain is testing DKIM. Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email. This covers both successful and failed verification. Verifiers MAY wish to track and report testing mode results to assist the Signer. This isn't quite right, I think. For a signed message that verifies, a negative reputation should still be considered applicable. A positive one should not. That's not equivalent to unsigned. It is if POLICY is applied. If the conditions are: DKIM record has t=y ADSP record has DISCARDABLE MAIL is unsigned (or failed to verify) Should ADSP processor honor the DKIM t=y? I don't think so since this opened the door to abuse. This is why the t=y flag was pulled from SSP draft rev2. This is why the text in I-D DSAP was: The t=y tag is optional. If defined, the domain is currently testing DKIM. Verifiers SHOULD NOT treat testers any different from production mode signers. It SHOULD NOT be used as a way to bypass a failed signature classification policies. However, verifiers SHOULD track testers for over extended usage of test signatures and MAY consider using the results to provide feedback to the domain. The issue is mixed up with the concept of domain experimentation and reporting, the desire to report results to domains during a testing/exploration phase and to make sure the receiver processor does not reject their bugs during the testing phase. Well, thats nice, but it opens the door for abuse and there are still domains out there since 2006 with t=y causing waste in processing their failed DKIM signatures, generally broken because it was passed thru middle ware (i.e. list server). But people wanted reporting, so in DSAP, a tag was provided for the email address but also guideline to track and limiting the reporting. DKIM doesn't cover reporting, so t=y can be considered less required. But I see no harm keeping it in as long as receivers and publishes are aware that it can't be used for change results. I think the current text is sufficient, but clarification could be added if warranted. Overall, I can see Advanced receivers do things like suggested in DSAP, advanced implementations can explore time limits for failure of domains with t=y before taking action. Tolerating it just waters it done and no one will pay attention to it anyway, most likely many DKIM implementations today. I know we don't honor it. I don't see any difference in regards to reputation. Either it trusted or not, passes or Fail or unknown, same type of fail processing has to be done. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
Barry Leiba wrote: That said, I'm inclined to agree with Mike T that input from the reputation target is suspicious, so it's not clear how much value it will have nor whether it might be gamed (by the reputation target) or hacked (by someone wanting to hurt the target's reputation). It shouldn't matter what t=y is or not, where the final result came from, technical or reputation. Unless there is a strong exclusive policy involved based on ADSP or some FUTURE REP-POLICY idea saying; ADSP: This mail must be signed. REP-POLICY: This mail must be a good reputation. The bad guy does not need to give any sort of signature or rep hints in the mail, and the mail is accepted anyway (or passes this test). At the very least, with ADSP we have the Author-Domain anchor always available to do policy test, but for reputation its dependency on a signer-domain, there is no technical possibility to get that information. So you need a signature (valid or not) for reputation in order for it to even work. Anyway, for t=y, verifiers SHOULD NOT treat testers any different from production mode signers. I think that is what is the intent now is for the current DKIM text, if not, it should be clarified. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
I've opened a ticket to arrange that t=y suppresses any positive impact domain reputation has in the next version of OpenDKIM, as an experiment. I'm inclined to leave well enough alone. That wouldn't have been an unreasonable interpretation six years ago when DKIM was new, but this is the first time someone's suggested that t=y mean something operational rather than just encouraging better logging and diagnostics. (I discount the don't penalize us for bad signatures theory since as you note people aren't supposed to do that even without t=y.) R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] The good ol' t= tag in key records
Murray S. Kucherawy wrote: And you thought this list was dead. I was asked to consult recently on some DKIM questions raised by a customer of a former employer. The questions involved the meaning of t= in DKIM keys and the text in RFC6376. The focus of this tag has always been, to the best of my recollection, the notion that We're only testing DKIM, so please don't punish this mail if the signature fails to verify. We nearly deleted this during the Draft Standard update because that's effectively the same advice we give to failed signatures in general, making t=y pretty much meaningless. The only interesting thing we say about it now is that if a verifier wants to be extra helpful, it could collect extra information about failed signatures referencing t=y keys to help the signer figure out what went wrong. That customer brought up an interesting point. t=y could also be useful for messages whose signatures do verify. Specifically, it could be used by a signer to say It's possible this message shouldn't have been signed by us. Please don't give it any preferential treatment based on our name's reputation if the signature verifies, which could then tarnish our reputation. Unlike the verification failure case, I don't think this has any practical use by an attacker because it's explicitly declining any special positive treatment. That means it's actually useful in the success case. Any comments about this? I talked to Dave last week as we happened to be at the same event, and he thought this warranted a new erratum against RFC6376. I've opened a ticket to arrange that t=y suppresses any positive impact domain reputation has in the next version of OpenDKIM, as an experiment. -MSK Keep in mind this has been a deeply discussed concept since SSP and even SPF. My input has always been t=y should not be tolerated for long durations. In other words, continued failures with t=y should allow receivers to take action. It was meant to allow companies to test trial the concept, not be used forever. There are domains out there that still have t=y for years and their stuff always fails - pure processing waste. That was the somewhat the semantics that was added. Let me check.. ok, DKIM has: Verifiers MAY wish to track testing mode results to assist the signer. That was the compromise text added after my input years ago because I was never of advocate of t=y nor reporting ideas. I think I had proposed text that actually added time limits, i.e. X months, Y Years, etc to encourage domains to get their the stuff right before bad reputations or direct actions weight in. It was the same concern I had for SSP in draft-ietf-dkim-ssp-01 and it was eventually removed by draft-ietf-dkim-ssp-02.Also keep in mind that DKIM has a Fail to No Signature concept so a strong DKIM policy could cause rejection. A t=y allows rejection to be preempted. This is what I had for the 2006 I-D DSAP. I do recall others did help with the text because I wanted to provide a start/end testing period concept, i.e, once a receiver sees it, it can be used for a new entry DB record and give the domain X period for testing. http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.7 4.7. DSAP Tag: t=y The t=y tag is optional. If defined, the domain is currently testing DKIM. Verifiers SHOULD NOT treat testers any different from production mode signers. It SHOULD NOT be used as a way to bypass a failed signature classification policies. However, verifiers SHOULD track testers for over extended usage of test signatures and MAY consider using the results to provide feedback to the domain. I was never an advocate of reporting ideas, hence see section 4.5 which added some of the same time limiting ideas as well. Verifiers should be aware this reporting address can be a source of an report attack vector (Section 7.4). One possible implementation considerations would to limit the report to one report only and to track the reception and/or response of the reporting. I should note, that t=y topics and threads were pretty extensive and what I had in DSAP was done as I saw was a general consensus and agreement from all the discussions, but again I, myself, was never a reporting advocate. I accepted the consensus for a desire for it, I just didn't support or add any code for it. Anyway, I think what DKIM has now is ok although I was not really keen with the assist the signer part. But it is good enough to open the door to allow receivers to get smart about it if abuse is seen. I do think that when abuse does become obvious it doesn't matter if it has t=y or not, but if it does, it can help make the decision faster to act on it. If your open ticket reflects what I am writing here, then I agree its probably good to clear that up. -- HLS ___ NOTE WELL: This list
Re: [ietf-dkim] The good ol' t= tag in key records
John R. Levine wrote: I've opened a ticket to arrange that t=y suppresses any positive impact domain reputation has in the next version of OpenDKIM, as an experiment. I'm inclined to leave well enough alone. That wouldn't have been an unreasonable interpretation six years ago when DKIM was new, but this is the first time someone's suggested that t=y mean something operational rather than just encouraging better logging and diagnostics. (I discount the don't penalize us for bad signatures theory since as you note people aren't supposed to do that even without t=y.) Its not the first time John. No Tolerance for continued failure with a t=y has long been advocated hence the current text for opening the door for tracking. The threads and discussions are long and deep on this matter. It was actually pulled from SSP. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] The good ol' t= tag in key records
And you thought this list was dead. I was asked to consult recently on some DKIM questions raised by a customer of a former employer. The questions involved the meaning of t= in DKIM keys and the text in RFC6376. The focus of this tag has always been, to the best of my recollection, the notion that We're only testing DKIM, so please don't punish this mail if the signature fails to verify. We nearly deleted this during the Draft Standard update because that's effectively the same advice we give to failed signatures in general, making t=y pretty much meaningless. The only interesting thing we say about it now is that if a verifier wants to be extra helpful, it could collect extra information about failed signatures referencing t=y keys to help the signer figure out what went wrong. That customer brought up an interesting point. t=y could also be useful for messages whose signatures do verify. Specifically, it could be used by a signer to say It's possible this message shouldn't have been signed by us. Please don't give it any preferential treatment based on our name's reputation if the signature verifies, which could then tarnish our reputation. Unlike the verification failure case, I don't think this has any practical use by an attacker because it's explicitly declining any special positive treatment. That means it's actually useful in the success case. Any comments about this? I talked to Dave last week as we happened to be at the same event, and he thought this warranted a new erratum against RFC6376. I've opened a ticket to arrange that t=y suppresses any positive impact domain reputation has in the next version of OpenDKIM, as an experiment. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
