Subject: [ietf-dkim] DKIM-BASE-00: Proposed Expiration Tag (x=) Description Change

From: "Hector Santos" <[email-masked]>
Date: Mon, 10 Apr 2006 23:15:13 -0400

I think the expiration tag (x=) should remain as part of the specification.

But functionally defined better as a message transaction (dynamic or
delayed) key management security concept.

NOTE: This is just a suggestion, "food for thought," for the authors to
consider. I purposely added more content than probably necessary so that
all related ideas can covered. Skip, prune, fine tune as necessary

Current:

 x=  Signature Expiration (plain-text; RECOMMENDED, default is no
     expiration).  Signature expiration in seconds-since-1970 format
     as an absolute date, not as a time delta from the signing
     timestamp.  Signatures MUST NOT be considered valid if the
     current time at the verifier is past the expiration date.  The
     value is expressed as an unsigned integer in decimal ASCII, with
     the same contraints on the value in the "t=" tag.

        INFORMATIVE NOTE:  The x= tag is not intended as an anti-
        replay defense.

     ABNF:

        sig-x-tag    = %x78 [FWS] "=" [FWS] 1*12DIGIT

Proposed change:

 x=  Signature Expiration (plain-text; RECOMMENDED, default is no
     expiration).  Signature expiration in seconds-since-1970 format
     as an absolute date, not as a time delta from the signing
     timestamp.  The value is expressed as an unsigned integer
     in decimal ASCII, with the same constraints on the value in
     the "t=" tag.

     The expiration is a DKIM signature descriptor exposing the
     responsible domain intent to define and control the DKIM
     signed message validity life span. Although this control
     might be viewed as domain key management and security
     concept, the domain's true intent and purpose is out of
     the scope.

     If present, the expiration time MUST be compared against
     the message transaction reception time.  Another name for
     this time is the Message Post Time.

        Informative Note:  In theory, message post time is not
        necessarily the same as the transaction reception time.
        The message post time could be the time the message
        as actually posted (saved) into a non-temporary message
        store after it has been received and pre-processed the
        by AU's AVS or Mail Filtering Agent (MFA) facility.

     Extracting the transaction reception time depends on where
     the DKIM verifier is operating at the AU.

          - Dynamic (transport) level,
          - Delayed Post Transport (storage) Level

     For dynamic verification operations, the transaction reception
     time is the current system time.

     For delayed verifications operations, the transaction reception
     time is the time extracted from the 2822.Received: header as
     required to be added by the transport SMTP receiver.  For
     non-SMTP based transactions, use the appropriate trace header
     to record and extract the transaction reception time.

     If the transaction reception time at the verifier is past
     the expiration date, the signature classification depends
     on whether the signature was checked for validation or not:

                Result when time has Expired

     =================    ===============================
     Signature Checked    Signature classification
     =================    ===============================
     not checked          SHOULD NOT be considered valid,
                          MAY choose to validate
     -----------------    -------------------------------
     valid                SHOULD NOT be considered valid
     -----------------    -------------------------------
     invalid              MUST NOT be considered valid
     -----------------    -------------------------------

     Verifiers MAY choose to not perform a DKIM verification
     before the expiration time is checked.

     If the signature is not checked, expired signatures SHOULD
     NOT be considered valid. The verifier MAY choose to perform
     signature check first before making the final classification.

     If the signature is valid, expired signatures SHOULD NOT be
     considered valid.

     If the signature is invalid, expired signatures MUST NOT be
     considered valid.

        INFORMATIVE NOTE:  The x= tag is not intended as an anti-
        replay defense.

     ABNF:

        sig-x-tag    = %x78 [FWS] "=" [FWS] 1*12DIGIT

Reasoning:

The expiration should be compared against the transaction reception time
(MSG.RCVDTIME) or Message Post Time (MSG.POSTTIME), not the current system
time (SYSTEM.TIME).

This resolves the question on whether the expiration may be used to
invalidate an already stored message by changing its status.

In theory, for transaction level DKIM verification operations

        SYSTEM.TIME = MSG.RCVDTIME <= MSG.POSTTIME

But for delayed DKIM verification operations, we have:

        MSG.RCVDTIME <= MSG.POSTTIME < SYSTEM.TIME

Where

    SYSTEM.TIME is the current computer time when the
    verification takes place.

    MSG.RCVDTIME is the current computer time the
    transaction was received. (Same as trace header
    Received: time)

    MSG.POSTTIME is the current computer time after the
    message was received and after it was pre-processed
    by MFAs (Mail Filtering Agents) and actually SAVED and
    RELEASED for user access.

For the most part, I think MSG.RCVDTIME should be viewed as the same as the
MSG.POSTTIME since it will typically be the same when the time resolution is
compared by the minute and the MFA overhead is low.  But this all depends on
the AU incoming mail processing practice.  I make the distinction because
most systems, well, I can only for ours, have a MSG.POSTTIME field  So if we
have add or a 3rd party developer adds a MUA based verifier, it would be
faster to get this time rather than read the Received line.  Small
distinction, probably not even worth mentioning.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Mark Delany <[email-masked]>
Date: Tue, 11 Apr 2006 05:14:30 +0000

> delayed) key management security concept.

Hector, you've done a great job of describing the mechanics as you see
it, for x=. In short you've describe "what" x= might mean really well.

What I'm not grasping - and I apologize for this - is the "why".

Why should verifiers care about an x=? What problem do you see it
solving? Particularly, what problem does it solve that a Selector
revocation doesn't solve?

You allude to an answer above with "key management security concept"
but I don't see any elaboration in your later text.

Mark.

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 11 Apr 2006 07:13:11 -0400

----- Original Message -----
From: "Mark Delany" <[email-masked]>

> but I don't see any elaboration in your later text.

Good morning,

I left the "reason" as out of scope because I think there are many reasons
why one might implement it, especially depending on what role you are
playing.

Lets ask it this way:

         What is the purpose of DKIM?
         And how does expiration help it?

>From the innocent verifier standpoint, its goal in DKIM might include:

        - Address the malicious transaction problem,
        - Quickly disseminate the bad from the good,
        - Reduce overhead,
        - Protect customers/users,
        - Help protect DKIM domains as a standard consistent protocol.

In short,  address the global spam problem.

Does expiration contribute for this purpose?

>From a verifier standpoint, it is looking to be told what is bad mail.  It
wants every piece of information the domain can expose to communicate levels
of control.

>From a signer standpoint,  If the domain is saying the expiration is one
such control to invalidate a signed transaction, then it is not up to the
verifier to decide if its useful idea or not.  The verifier will not know
the "true intent" of the domain's control here.  Why should the verifier not
honor it?

This is also addresses your previous question regard the application usages
and there they serve any useful purpose.   That all depends on your role.

I apologize if this short answer doesn't fully describe my overall opinion,
but I will say that DKIM is short on controls or fail detection ideas in
DKIM.

What is unique about Expiration is that it is probably the only clear item
in the DKIM protocol that helps with failure detection:

  expiration ----> clear definition for invalid,
                             no verification required.

  key change --> fail hashing,
                            viewed as never existed.

So is there a higher invalid "weight" with the clear expiration detection?

The specs already implies to not reject if the signature fails.  So
deprecating the expiration descriptor will fall in line with the going on
philosophy.

Any who, I think it is useful.  Whether how useful it is for the signer,  it
open to many interpretations based on what role you are playing.

---

From: Mark Delany <[email-masked]>
Date: Tue, 11 Apr 2006 19:37:43 +0000

> open to many interpretations based on what role you are playing.

And that's a bit of a concern to me. A signer may use it for one
purpose, some verifiers another and different set of verifiers (or MTA
packages) for a third purpose.

That "fuzzy" semantic use seems to mean that we'll end up with a
signer never knowing for sure exactly what the outcome will be.

I guess what I was hoping for is a crisp set of instructions to
deployers as to what they should set, why they should set it and what
outcome they can expect as a consequence.

Mark.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Apr 2006 07:38:25 +0200

Hector,

>         - Address the malicious transaction problem,
How, and why is this the best method (as opposed to either removing the
selector from DNS or having the x= value within the key record itself)?
>         - Quickly disseminate the bad from the good,
Again, how?  And I don't think you meant disseminate, but discriminate. 
Does a message suddenly become "bad" because the signature expired?  And
what do we mean by "bad" here?  If it is because the key will likely be
cracked over some period of time, wouldn't a verifier understand this
based on the key type, and why would it distinguish one domain from
another in this case?  If it is not because the key is cracked, then we
are into non-repudiation which is out of scope.
>         - Reduce overhead,
You're talking about DNS queries?  I'm not sure I see it.  I would
expect the VAST majority of queries to occur within days if not minutes.

>From what?

I'm sorry, I don't understand this either.

> the "true intent" of the domain's control here.  Why should the verifier not

I'd be happy with this logic if you could give me a single legitimate
purpose for this.  Thus far I haven't heard any.

>                              no verification required.

But what does this mean?  If I am an administrator how would I use this
to provide either myself or the recipient with some value?  What does it
mean for a signature to have expired in this context?  Does it mean that
the message is less trustworthy than it was prior to expiration?  Please
show me a real use case.

Thanks,

Eliot

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 12 Apr 2006 06:43:39 -0400

----- Original Message -----
From: "Eliot Lear" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> Again, how?  And I don't think you meant disseminate, but discriminate.

Actually no, disseminate, as in "Query Dissemination" methods,  which in
terms for this context;  to zoom in on an answer or decision efficiently by
using information available to help separate or eliminate your less probable
choices. i.e. Eliminating the obvious first.   What is optimal in query
dissemination is to do this with little overhead.

For DKIM,  factors such as:

     - Expiration,
     - Broken Signing Policies,
     - Syntax errors
     - Other inconsistencies, and
     - other ideas we want to add to help the process.

are all useful for disseminating and as such, it inherently give you a high
payoff and efficiency.  Although we might label them as "bad," this has
nothing to do with reputation. It more about following the rules.

> Does a message suddenly become "bad" because the signature expired?

I don't think I implied that, in fact, I believe my proposal to use the
message reception time eliminates this idea.

By the way, I am curious.  I am wondering why is there is a resistance to a
expiration concept?  Isn't  expiration an inherent attribute in security and
in a crypto key concept?

Are you now a bad driver because you driver license has expired?  Maybe you
are not a bad driver, but you are an illegal driver in the eyes of the
state.  Maybe considered even a "bad  person" because you not playing by
society protocols. :-)

Anyway,  I was hoping DKIM can be used as a deterministic protocol, and if
someone thinks an expiration" concept applies in the area of Key Creations,
Managment  and Usage, I think I will have a hard time arguing against it.
But if you administrator guys think its more of a pain than useful, well,
maybe it should be nixed.

>From an verifier standpoint, if the concept is part of the protocol, then
you follow it and honor it and don't question why the signer had this
practice.  There could be many reasons why the signer has this practice.

>>         - Protect customers/users,

Malicious mail or harm to the system?  .

> I'm sorry, I don't understand this either.

I hope I don't badly paraphrase Mr. Crocker, but essentially the mantra is:

        DKIM is a protocol that assigns responsibility for
        a domain and hence their reputation is at stake.

Yet, the only thing DKIM-BASE wants the verifer to do is:

       - Find One GOOD signature

even if among a sea of bad signatures.  It essentially ignores all
inconsistencies, all failure and all information that will allow a system
incorporating DKIM, among other things, to help a domain keep its
responsibility and reputation in line.

> purpose for this.  Thus far I haven't heard any.

I listed three in:

http://mipassoc.org/pipermail/ietf-dkim/2006q2/003125.html

I think can come up with a few more useful ideas if needed.

>> What is unique about Expiration is that it is probably the only
>> clear item in the DKIM protocol that helps with failure detection:
>>
> to provide either myself or the recipient with some value?

I was referring to how there is a mixed philosophy where you have:

    Verification is performed:

          result = valid  >>>> Accept
          result = invalid >>>> Ignore as it never happen

     No Verification Required:

          Expiration  >>>>>> Reject

Even though this would be an efficient dessemination,  the idea is incorrect
with the signature checking results.  This is why in the proposal I
presented,  I added  the factor of checking for a lid signature before
checking for expiration.   This actually makes it less strict then the
current proposal and more inline with the rest of the specs.

> Please show me a real use case.

Well, it can't be real because it doesn't exist :-)

But given the option,  I definitely see how it can be applied.   I gave 3 in
the above link.

Lets see another:

o High Value vs Low Value Email.

Bank believes in DKIM.  It signs all mail and sends various promotions
including billing info to email account/customers.

Sends two messages using same selector

        a) Promotional (AKA spam), adds 6 day expiration.
        b) Billing info, adds 2 day expiration

Now keep in mind this expiration is delivery time limit.  It will be
worthless for the verifier to accept these signed messages if they havn't
been received withn the indicated time frame.

o  Security Consultant hired to write new security procedures for IT.

He recommands all mail to be signed and that all signed messages have 2 week
expirations for delivery.

Note: I guess at the numbers, but I can see where for important email you
don't want this to be floating around the transport system long as it might
indicate there is a delivery trouble somewhere.

Anyway,  I think its useful.  I don't see it harming anything and it can add
value.  I vote to keep it.   If there is more harm, then lets ditch it.

But I also agree with Mark that it can be sidelined and allowed to be
introduced as a helper protocol, like the one I'm writing called DSAP (DKIM
Signature Authorization Protocol).  I don't see expiration as important as I
do with signing authorization in general.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Apr 2006 13:27:07 +0200

Hector,

Thanks for your note.  Please see below.

> expiration concept?  Isn't  expiration an inherent attribute in security and

Yes, it is.  However, such expiration is usually associated with a key
as part of a certificate for purposes of truncating  revocation lists or
otherwise limiting the damage that could be caused due to lost or stolen
private keys.  Under the  cryptographic systems I understand a signature
will verify as valid so long as the input was signed prior to a key's
expiration.  Put another way, you normally can validate a signature long
after the key used to generate it has expired, so long as the key was
valid when the signature was made.

The problem here is that we are associating the expiration time with a
message that is signed with such a key, and not the key itself.  And so
the semantics are different.   x= says that the verifier should not try
to retrieve a key from DNS past a certain date.  If the purpose is to
simply not have the message validate at all at some period of time, that
is fine but that should be documented clearly (and further justified IMHO).

Eliot
ps: thanks to Landon Noll for providing me some guidance on the nature
of cryptographic signatures.

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 12 Apr 2006 12:55:25 -0400

Eliot,

Thanks for this.  It helps. It highlights that meaning,  usefulness,
heuristics,  etc, all depends on the disciplines and roles.  We have
security, network, application developers, protocol developers, support
people, managers,  QA people and possibly even users, each with there own
(and correct in their right) ideas.

What I am commenting on is that there is a natural protocol here that we
need to work out that needs to fit with the current infrastructure.

Specifically, if expiration is a natural part or security consideration of
the technology being explored,  removing it for consideration probably isn't
a good idea.

If the semantics is the problem, then lets fix the semantics.

I think the questions that need to be ask is:

    a) Is Expiration applied to key validity?
    b) Is Expiration applied to transient only time verification?
    c) Is Expiration applied to Message "Death-Dates"?

The information note should be, in my opinion, is that it shouldn't matter
once the message has been received *by* the user.   This is consistent with
Dave's "Car in the Intersection - Light Turning Red" metaphor.

I also think, as my proposal highlights, there are two cases here:

     - Expired Valid Signature
     - Expired Bad Signature

The current semantics excludes the validity of the signature and probably
this is because the semantic is associated with option (a) above.

---
Hector