[ietf-dkim] Proposal: Do the semantics first, then straw poll
dotis at mail-abuse.org
Mon Apr 17 13:39:01 PDT 2006
On Apr 17, 2006, at 12:11 PM, Jon Callas wrote:
> x= is a good thing because many, many people will change their DKIM
> keys every time they change what mail server they're using. This
> key will have a years-long, if not decades-long life.
x= is a bad thing, as it allows bounce exploit timing to be tuned per
message. Those that find themselves handling messages they accepted,
but then can not deliver due to the down-stream system not accepting
messages with too little remaining expiry time, may then lead to an
ever escalating amount of time being required for acceptance.
> Using x= lets them blow off bit rot in messages that they are
> "responsible" for. I also believe that it is a Good Thing that DKIM
> is not an archival signature system for many privacy-related
> reasons that are tangential to this discussion, and x= kinda sorta
The x= will not offer a significant reduction in replay exploits.
The x= time window will need to be large enough to ensure delivery,
which does not impose a substantial burden for bad actors who burn
accounts as their cost of doing business. Handling that rejects a
message 1 second past expiration will induce a worse problem than
would a replay exploit. Bounced expirations from reputable sources
will require a secondary reputation be ascertained (after the DATA)
phase by checking unsigned message Received headers. How does expiry
reduce the burden or limit the accountably?
It would be better to have a mechanism that can be used to silently
discard messages when so identified by the sender as having been
revoked. There should be a separate status for retired keys
however. If the desire is to have lazy key management, then have
keys marked as being retired at some time. Stopping using these keys
some number of weeks before this retirement date. Publish enough
keys to handle the next few years of email signing, and simply change
the selector on a schedule.
> It can be described in BCP documents, HowTos, and so on.
How is this problem avoided by special handling, when a finely tuned
per message expiration is a basis for rejection by some servers?
> But when it comes down to brass tacks, some weird combination of
> SSP, BCP, receiver filtering/delivery policy and so on is going to
> come into play, but *only* *when* *an* *abrupt* key change takes
This would only be true if x= were removed.
> In the normal, running environment, it doesn't matter whether we
> have x= or not.
For a safe running environment, not having x= causing exploits would
be important. The safe alternative would a retirement date published
with the key.
More information about the ietf-dkim