Subject: [ietf-dkim] proposal: retain x=

From: Michael Thomas <[email-masked]>
Date: Sat, 08 Apr 2006 16:49:48 -0700

The current proposal to remove x= has normative text which
requires verifiers to hard code a value that approximates the
maximum transport time of SMTP. There are many problems
with this:

1) These transport times are only informally known, but putting
     an absolute value in the DKIM spec, we will make it to brittle
     to any changes for that assumption
2) DKIM has hooks for other services other than SMTP, and it
    is certain the that new services will not share a common transport
3) By designating an absolute value in the spec, this proposal retains
    the same failing that it claims as a motivation for removing x=. That
    is, clock skew will still need to be considered, etc.

For these reasons, I propose that we retain the current semantics of
x=. Adding informative text to aid the signer in choosing a value
of the expiration time, including some discussion of the clock skew
issue would be helpful.

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

---

From: Mark Delany <[email-masked]>
Date: Sun, 9 Apr 2006 02:26:14 +0000

>    is, clock skew will still need to be considered, etc.

Fine. But I've still not seen a compelling argument for x= that cannot
be effectively achieved by revocation of the selector.

> x=.

As with every part of DKIM, retention needs justification. Michael,
what's the compelling argument for x=? What do we lose by not having
x=?

Mark.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 08 Apr 2006 19:40:48 -0700

>be effectively achieved by revocation of the selector.
The same reason that you've tirelessly advocated that DK selectors
be backward compatible: that many sites only have a rather tenuous grip
on the manageability of their DNS entries for DKIM.

       Mike

---

From: John Levine <[email-masked]>
Date: 9 Apr 2006 04:32:09 -0000

>> maximum transport time of SMTP.

Good point.  Change it to:

 Receivers SHOULD NOT interpret signatures older than the maximum
 transit time of the service used to deliver the message.  In the case
 of SMTP[RFC2821, Sec 4.5.4.1] the maximum transit time is typically a
 week.

>>     to any changes for that assumption

I don't see anyone other than perhaps you advocating putting an
absolute value in the spec.  RFC821 and RFC2821 have only non-binding
suggestions for timeouts and retry intervals, and leave the sender
retry schedule almost entirely up to the sender, and they work fine.

In our case, a recipient knows just as well as a sender (maybe better)
how the message arrived and what the likely max transit time is, and
can pick and apply an appropriate timeout with no help from x=.

Perhaps we have a confusion between precision and accuracy.  It's
true, with x= you can set a very precise time limit, but that doesn't
mean it accurately states the useful life of a signature.  If I were
writing DKIM code, I'd say I dunno, it's about two weeks, which I then
encode as 1,209,600 seconds.  That looks really precise, but we all
know as an estimate of transit time, it's give or take several days at
least.  So don't bother.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Sun, 09 Apr 2006 10:34:39 +0200

> on the manageability of their DNS entries for DKIM.
If the key is cracked having x= in the message will be pointless.  Your
only recourse is to withdraw the key from DNS.  Perhaps the
administrative burden can be eased by delegating the .domainkey.domain
portion to the mail administrator.

Eliot

---

From: Mark Delany <[email-masked]>
Date: Sun, 9 Apr 2006 14:25:41 +0000

> on the manageability of their DNS entries for DKIM.

An interesting guess as to my motives, but no, that's not why I do
that advocating.

But I get you're answer. You're saying that x= is there solely because
some people will have trouble removing a key when it's compromised.

Mark.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Apr 2006 06:42:09 -0700

> An interesting guess as to my motives, but no, that's not why I do

It's certainly what Arvel has been advocating.

> some people will have trouble removing a key when it's compromised.

It has nothing to do with compromise. x= is the difference between
routine maintenence of DKIM DNS records required (where routine is
approximately every two weeks) vs. install a selector once and not
worry about it for a long time.

		Mike