[ietf-dkim] Proposal: Do the semantics first, then straw poll

[Douglas Otis]

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

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

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.

-Doug