Subject: [ietf-dkim] The good ol' "t=" tag in key records

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 21 Jul 2012 21:50:46 -0700

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

---

From: "John R. Levine" <[email-masked]>
Date: 22 Jul 2012 01:23:57 -0400

> 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

---

From: Hector Santos <[email-masked]>
Date: Sun, 22 Jul 2012 10:41:38 -0400

> domain reputation has in the next version of OpenDKIM, as an experiment.

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

---

From: Hector Santos <[email-masked]>
Date: Sun, 22 Jul 2012 11:00:16 -0400

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 22 Jul 2012 19:01:04 -0700

> aren't supposed to do that even without t=y.)
That's certainly true, but then again actual reputation services based on
DKIM hadn't been developed back then.  Maybe an applicability statement
will be a good thing to do once this has been explored a little more, or it
could be included in progression to IS status.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Jul 2012 09:13:47 -0400

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jul 2012 06:41:59 -0700

On Mon, Jul 23, 2012 at 6:26 AM, Richard Dawe
<[email-masked]>wrote:

>
> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jul 2012 06:47:44 -0700

On Mon, Jul 23, 2012 at 6:42 AM, Michael Thomas <[email-masked]> 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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Jul 2012 10:04:11 -0400

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jul 2012 06:44:58 -0700

> sent by bad guys.  Give us a break until we get things straight."

Right.

Otherwise, I'm fine with that path if others are.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Jul 2012 07:28:34 -0700

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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Jul 2012 06:51:13 -0700

On 07/23/2012 06:47 AM, Murray S. Kucherawy wrote:
> On Mon, Jul 23, 2012 at 6:42 AM, Michael Thomas <[email-masked] <mailto:[email-masked]>> wrote:
>
> 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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Jul 2012 06:42:09 -0700

Mike

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jul 2012 08:20:12 -0700

>          Verifiers MAY wish to track and report testing mode results to
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

---

From: Hector Santos <[email-masked]>
Date: Mon, 23 Jul 2012 12:42:48 -0400

> 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 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

---

From: Hector Santos <[email-masked]>
Date: Mon, 23 Jul 2012 13:06:11 -0400

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Jul 2012 14:32:40 -0700

On Wed, Jul 25, 2012 at 10:42 PM, Roland Turner <
[email-masked]> 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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 26 Jul 2012 14:38:26 -0700

On 7/23/2012 8:20 AM, Murray S. Kucherawy wrote:
> On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> 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/