ietf-dkim
[Top] [All Lists]

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

2012-07-22 10:19:19
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 operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html